[Esd-l] Detection rule for sendmail header exploit

[Joe Steele]

On Friday, March 07, 2003 9:49 AM, John D. Hardin wrote:
>
> On Fri, 7 Mar 2003, daniel lance herrick wrote:
>
> > On Thu, 6 Mar 2003, John D. Hardin wrote:
> >
> > > * ^(From|To|CC|Reply-To|Resent-From): .*<>.*<>.*<>.*<>.*<>.*\(.*\)
> >

[snip]

>
> There are two possible weaknesses in the above RE:
>
> 1) that the <> pairs can be non-empty and the exploit still works, and

>From what I see in the sendmail code, the allowable buffer overrun 
increases (up to a limit) with each unnested pair of <> (nested pairs 
do not contribute), and it does not matter whether the pairs are 
empty or *non-empty*.  

The published exploit relies on being able to store "aptr" at offset 
OFF3+l (i.e., at offset 306), which requires overrunning the buffer 
by 60 bytes (by my count, which is only approximate: 60 = 306 - 250 + 
sizeof aptr).  So it needs at least 60 pairs of <>.  The exploit uses 
138 pairs, so the extra pairs end up being filler which pads the 
buffer.  This padding could be replaced with arbitrary text 
interspersed inside and outside of the pairs of <>.

Based on the comments above, the pattern ".*<>.*<>.*<>.*<>.*<>" is 
easily bypassed.  And although the pattern 
".*<.*>.*<.*>.*<.*>.*<.*>.*<.*>" should trap any exploit, it is too 
simplistic because lists of addresses will also be caught.  To be 
effective without casting too large a net, each address in a list 
needs to be scanned separately.  Attempting to do this with a regular 
expression could get complicated.

The brute force method of trimming headers down to 250 bytes would 
probably be effective at blocking any exploit, but I doubt that it is 
a reasonable solution, particularly for recipient headers.  (In 
reality, the 250 byte limit need only be applied to each individual 
address in a list.)

Another point to note is that the RE should begin with the following 
in order to trap all headers for which sendmail is vulnerable:

* ^((resent-)?(sender|from|(reply-)?to|cc|bcc)\
    |(errors|disposition-notification|apparently)-to):

>
> 2) that the comment can be unterminated - no trailing ) - and the
> exploit still works.

I wouldn't rely on the presence of parentheses, because I don't think 
they're that critical to the success of the exploit.  All they do is 
surround 28 NOP's.  Sendmail doesn't care whether the NOP's are 
inside a comment.  I suspect the intent was to protect aptr inside 
the parentheses (because doing so would make sense), but the code 
stuffs aptr right after the ")" instead, and yet it still works.

--Joe