-----BEGIN PGP SIGNED MESSAGE----- lcamtuf> a) Sendmail (tested with 8.9.3 and previous) allows you to put lcamtuf> mail addressed to eg. '|/bin/sh' (or any file) into mail lcamtuf> queue. Fortunately, this queue file should contain also line lcamtuf> like 'Croot' to be processed properly, while we have no idea lcamtuf> how to put it there. But, anyway, seems to be dangerous - lcamtuf> Sendmail should reject such crap immediately: lcamtuf> /usr/sbin/sendmail -O 'DeliveryMode=d' '""|/bin/sh' lcamtuf> (without these double-quotes, it _will_ immediately drop your lcamtuf> message) As you have noted, this appears only to be possible with an outdated .cf file and an 8.9.3 binary. However, even in this case, the address is not accepted as there isn't a valid controlling user. We have run through the possible scenarios we could find and do not believe this to a threat. Also, as people upgrade their binaries, they should upgrade their configuration and this should not be an issue. lcamtuf> b) Into queue files (qf*), Sendmail stores internal delivery lcamtuf> information, user-supplied headers (Hxxx) and server-added lcamtuf> headers (H?x?xxx). These headers are handled in several lcamtuf> different ways, depending on letter between '?' - but, in lcamtuf> general, are used to store default values for other headers lcamtuf> (like 'Date:' and 'Return-Path:'). But, headers like: lcamtuf> ?D?My-Own-Header: junk lcamtuf> are allowed in messages, and are put in unchanged form into lcamtuf> queue files, allowing possible conflicts or MTA confusion :P lcamtuf> For example, header '???This-Causes-Error: test' causes odd lcamtuf> error messages during message processing. What does it mean? lcamtuf> Probably nothing dangerous, but I haven't spend enough time lcamtuf> investigating this issue to be sure, maybe it's some way to lcamtuf> cause undesirable MTA behaviour. Agreed, this is a bug. The next beta version of 8.10.0 will not have this problem. Given this isn't a security problem, it will not be fixed for 8.9.3. lcamtuf> c) Sendmail won't put X-Authentication-Warning header (eg. about lcamtuf> protocol violations, suspected options etc) into message if lcamtuf> there's one already present - no matter how stupid it is. Minor lcamtuf> bug. This is also fixed in the next beta version of 8.10.0. lcamtuf> So, another thing. There's nice remote Sendmail ETRN DoS. When lcamtuf> ETRN command is read by Sendmail (it shouldn't be allowed at all, lcamtuf> IMHO), it calls fork(). Parent process generates no output - only lcamtuf> child-generated output is sent, so parent won't be notified on lcamtuf> send()/write() failure. If we drop connection (after sending a lot lcamtuf> of ETRNs), parent process will stuck, doing repeately fork() lcamtuf> ... sleep(5), till end of ETRNs read into input buffer is lcamtuf> reached. This allows us to spawn any amount of 'unusable' sendmail lcamtuf> childs, hanging for long period of time - and it can be done using lcamtuf> low network bandwitch and resources. Direct result - all server lcamtuf> memory consumed (causing Linux 2.0 kernels to crash with messages lcamtuf> like 'no memory for sendmail', 'no memory for klogd' etc). Unlike lcamtuf> connect() flooding, this attack is generating low traffic, only lcamtuf> one connection at time, and seems to be deadly harmful, unless lcamtuf> something like: lcamtuf> # maximum number of children we allow at one time lcamtuf> O MaxDaemonChildren=15 Yes, MaxDaemonChildren will avoid this sort of denial of service attack. However, the fact that sendmail buffers up commands after a remote side drops its connection is a bug. This bug will be fixed in the next 8.10.0 beta release. Once again, thanks for bringing these bugs to our attention. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0 for non-commercial use Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface Charset: noconv iQCVAwUBOH4H/XxLZ22gDhVjAQH2jwP9HuMCOdSuROR1E5VFUIp+s+6TtGALNzh3 1tkO2L8LYav2FztbYQjI3kjdCAcocGZGW6k6vKoxU4b/3Y6Z/rEVs6QWTLick4Ei uVk8ZIrq0Br4s4XEZg1V3x1U0Ex+1KPmlLmDqRyJYUio3wPV0Zie0CHbzAKavUlH q5ze6Hq/m6k= =955/ -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:27:59 PDT