Re: CVS commit: src/lib/libpthread
In article 20141217014908.359b...@cvs.netbsd.org, Antti Kantee source-changes-d@NetBSD.org wrote: -=-=-=-=-=- Module Name: src Committed By: pooka Date: Wed Dec 17 01:49:08 UTC 2014 Modified Files: src/lib/libpthread: pthread_makelwp_netbsd.c Log Message: include correct header for last minute just-in-case defensive addition that's too trivial to check Please rename the file pthread_makelwp.c; calling a file _netbsd.c in a NetBSD tree for a NetBSD implementation is bogus. christos
Re: CVS commit: src/usr.bin/mail
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? I believe that all maintained versions of mail upstream are being adjusted to comply with this. What's the downside? Or are you sure that everything that passes addresses to the mail program command line sanitizes their addresses properly? christos
Re: CVS commit: src/usr.bin/mail
This is fully yours and who am i but Christos Zoulas chris...@netbsd.org wrote: |Module Name: src |Committed By: christos |Date: Tue Dec 16 19:30:24 UTC 2014 | |Modified Files: | src/usr.bin/mail: cmd3.c extern.h fio.c mail.1 names.c send.c | |Log Message: |Fix various security related issues: | |0001. Do not recognize paths, mail folders, and pipes in mail addresses |by default. That avoids a direct command injection with syntactically |valid email addresses starting with |. | |Such addresses can be specified both on the command line, the mail |headers (with -t) or in address lines copied over from previous |while replying. |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. --steffen
Re: CVS commit: src/usr.bin/mail
In article 20141217142550.ne2degkj%sdao...@yandex.com, Steffen Nurpmeso sdao...@yandex.com wrote: 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. It is to protect the innocent. Consider someone writing his first cgi script and wants to add mail functionality :-) Perhaps as people claimed mail/mailx is beyond hope... christos
Re: CVS commit: src/usr.bin/mail
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
