[Esa-l] html-trap.procmail 1.113 a bit too hair triggered...

[Bjarni R. Einarsson]

On 2000-07-24, 13:46:52 (+0100), Matthew Seaman wrote:
> 
> Got a false positive here on a valid Message-ID.  I guess a few more dots in
> the RE at line 146 of html-trap.procmail might be in order?  According to the
> exploit script at
> 
> http://www.securityfocus.com/data/vulnerabilities/exploits/outoutlook.pl
> 
> it takes more than 945 characters to overflow the buffer in Outlook: this
> patch allows header lines up to 256 characters after the colon.  As my mailer
> would now proceed to wrap those lines at 78 characters, the patch is
> uuencoded...

I'd actually be very interested to hear how many characters
people consider "safe" - how much uninterrupted crap is
generally required to create a working exploit.  How much is
needed to overflow a buffer probably varies quite a bit, and
blindly using the Outlook numbers doesn't strike me as a good
idea.

I also have the sneaky feeling that it doesn't always take that
many bytes to write an exploit... anyone here who has seen the
demos people could write in 4k on the PC will know where I'm
coming from. :-)  The exploit demo'ed on Bugtraq did quite a few
things, I suspect tighter code could have still left the system
vulnerable well within 256 characters (assuming the buffer gods
were willing).

In my sanitizer (which is not the same as John's, although they
are related), I attacked this problem using the following
regular expression:

 $part->{"rawheader"} =~ s/(\S{120,120})(\S)/$1 [Split:$pid] $2/gs;

This allows individual headers of inifinite length (which is
nice for long subjects, etc.), but limits the length of
individual words to 121 characters.  Any word exceeding this
limit is split in two, and a variable-length marker inserted
between them.

My theory is that exploits like the Outlook Date-bug will rely
on very long words more often than long headers.  I think I'll
spare the list a detailed explanation of why, but please don't
hesitate to let me know if you think I'm wrong.

What do people think of this approach?  It is more forgiving
than John's, and therefore less secure... but it is still in
some ways stricter than Matthew's patch.  Food for thought
anyway. :-)  Perhaps a combination would be best?

Also, if there are any people on this list familiar with how
exploits are written, I'd be interested to hear how they'd try
to circumvent either (or both) approach.

-- 
Bjarni R. Einarsson :: bre at netverjar.is :: http://bre.klaki.net/