Re: CVS commit: src/usr.bin/mail

[Steffen Nurpmeso <sdaoden%yandex.com@localhost>]

christos%astron.com@localhost (Christos Zoulas) wrote:
 |In article <20141217131849.r2prGpJe%sdaoden%yandex.com@localhost>,
 |Steffen Nurpmeso  <sdaoden%yandex.com@localhost> 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