(Do you really not want replies going to the list? You've got your Reply-To set, and my MUA rightly things that this means replies should go to you privately) On Wed, 16 Jul 2003 17:19:55 +1000 Russell Coker <russell@coker.com.au> wrote: > In mail servers such as Postfix and Qmail the received mail goes through a > number of programs before getting delivered. The authors of these programs > have done as much as possible to ensure that no program gets needless access > to the system. With my SE Linux policy to enforce this the only way that > Procmail or other delivery agents get run is through the local delivery > agent. This means that if you want to exploit Procmail, the scripts that > users put in their .forward files, or whatever else may be exploited then you > have to do it by proxy through the regular mail delivery mechanisms. So > unless you exploit the local delivery agent then Procmail or other delivery > programs have to receive something that vaguely looks like an email message > (which may not permit the exploit). > > If the vulnerability in the delivery process which runs as root requires that > it be fed grossly bogus input data, and if the process which feeds it data > will not feed it invalid data then you don't get anywhere. > > Is this really so difficult to understand? Nope, it's not difficult to understand your reasoning - but I don't agree with the underlying assumption that all (or many) of the links in the chain need to be successfully exploited before you can get root. Let's play with Postfix; say there are stages 1, 2, and 3, which are run as nonprivileged users, and then there's stage 4, which runs as root before dropping privileges. If they all share the same code, then what you're describing is irrelevant; if the vulnerability exists in 4, it's overwhelmingly probable that 1, 2, and 3 can be exploited to bypass all sanity checks. If they don't share the same code, then why assume that the vulnerability in 4 can only be exploited by something that "vaguely" looks like an email message? Frankly, there is a lot of room in the spec to do all sorts of things, there's a lot of code involved. The last Sendmail vulnerability I remember could be exploited from a perfectly valid e-mail message. So all those seperate stages don't help - they will have passed this perfectly valid message happily on to the code that runs as root. The last Exim vulnerability (which was a good while ago, and was the first one in a long time, and which could only be exploited by users in the "trusted" group [ie: mail and root on any sane system]) was in CLI parsing. Should we then say that one needs to "exploit" the shell in order to pass such obviously broken parameters to Exim? Of course not, because there is nothing wrong with passing those arguments to an application, it's perfectly valid. So until somebody can convince me that the majority of vulnerabilities found in the code which runs as root have been triggered by invalid messages (as opposed to the payload of the exploit, which will undoubtedly be un-uuencoded :), I'll have a hard time swallowing the "they both run as root, but this one is safer because it's run later on in the chain" argument. Especially given that exim passes messages to itself when it needs to raise privileges - when you look at how the program actually works, it's much like postfix in that there's is very good seperation of process space. The root-running stuff is passed the message (which if found invalid will only have broken a nonprivileged process), it's not calling functions with pointers that may have an exploited payload. Of course, the entire "it's difficult to audit it because it's monolithic" may be quite accurate, but I'd need to delve deeper into Exim code than I have (what I've seen so far is pretty clear, but I've only touched on those parts which are meant to be used by others, like the filtering stuff). But since they're all just given messages instead of stuff on the stack (much like Postfix I'm guessing), they only need to get the message parsing code right once.
Attachment:
pgpzDweHxRrCh.pgp
Description: PGP signature