chris...@astron.com (Christos Zoulas) wrote: |In article <20141217131849.r2prgpje%sdao...@yandex.com>, |Steffen Nurpmeso <sdao...@yandex.com> wrote: |>This is fully yours and who am i but |> |>|Added expandaddr option to explicitly enable this behavior. |> |>why does a Christos Zoulas silently wave through this sloppy |>programmed shit from oss-sec that simply returns from outof() |>instead of giving any indication on what is going on? |>Unbelievable. | |All you have to do is to set a variable to get the previous behavior, |and this is now documented. It is unexpected behavior that a mail |program can run commands on behalf of the user using special syntax. |Just a few weeks ago, we fixed a similar issue in ftp. Why didn't you |complain for that?
ftp is completely beyond my horizon except for open/close/mreget. What is expected behaviour. But yes it is better if there are ways to disable it, i also see this now. |I believe that all maintained versions of mail upstream are being |adjusted to comply with this. What's the downside? It seems i'm the last. Missing checks, complete silence, no report at all, e.g. exit status. Bad programs. |Or are you sure that everything that passes addresses to the mail |program command line sanitizes their addresses properly? No, of course not -- except that "validate user input" screams from every wall. Maybe i'm just disappointed. But any environment that passes a string that includes shell meta characters through to whatever else seems broken. Tomorrow BSD Mail / POSIX mailx(1) get a CVE for QoS attacks because of passing through malformed addresses to MTAs that lead to nowhere but cause several process lifetimes and log entries... That doesn't seem right. --steffen
