[Esd-l] Perhaps it's possible to protect against this bug?

John D. Hardin jhardin at impsec.org
Mon Feb 11 07:18:01 PST 2002

On Sun, 10 Feb 2002, Brett Glass wrote:

> It seems to me that it would be possible to protect against
> the bug described below by checking blocks beginning with "begin"
> to ensure that they're really UUENCODEd. It should be possible
> to do this with a simple filter and add a > at the beginning
> of the line (as is done with the word "From") to prevent
> Microsoft Outhouse^H^H^H^H^Hlook from being messed up by this bug.
> Whaddaya think?

See below.

> From: Bear Giles <bear at coyotesong.com>
> Yet another Microsoft Outlook exploit is on the loose...

In what way is this an exploit? How does it permit the attacker to
execute code on the victim's system? How does it violate security?

> Prudent programmers will use a starting pattern such as
>  "\n\nbegin ([[:octal:]]+) ([^\n]+)\n"
> and subsequently verify that each line has the expected format.

The programmers at Microsoft obviously are not prudent.

One wonders if the current Feature Freeze Let's All Fix Bugs will have
any effect on this one?

> Naturally, it hasn't taken long for the malware writers to jump on the
> bandwagon.  All you need to do to get around the "strip executable
> attachment" killjoys is to put the malware right in the body of the message!
> Just start a line with "begin 666 www.myparty.yahoo.com" and you're off and
> running!

A "strip executable attachment" filter package that ignores UUE-format
attachments is... well... I can't really think of a properly scathing

> Microsoft's official position, at
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q265230 , is
> stunning in it's <s>feeble-mindedness</s> simplicity.

And is par-for-the-course Microsoft "it's not *our* problem" spin

> That's probably related to the fact that UUENCODE was defined by

There's a formal definition/standard for UUENCODE?

> not SMTP, and that every encoder/decoder I have seen requires a
> leading blank line and a octal file permissions code.

MS ones historically have not required the file permissions code.
Hence the ease of using this to annoy OE users.

> But the damage is done - since malware is exploiting this bug we
> now get to put into place filters that don't just strip executable
> attachments or properly formatted UUENCODED blocks, we also have
> to strip *improperly* formatted UUENCODED blocks!

Annoyware, more properly.


I've run across the discussion of this before. It's not a security or
DoS exploit so I don't feel too interested in putting it into the

If you care, try this on for size (untested):

   :0 B fb
   * ^begin[ ][ ]
   | sed -e 's/^begin  / begin /'

---------------------^^  note the TWO spaces!

Yes, this probably *will* disable genuine UUE attachments if they are
generated without permissions bits. For a digested mailing list, the
only place where the "DoS" is really apparent, you probably want to
strip all real UUEs anyway, then pass it through this to avoid the OE
bug on fake attachments or innocuous body text that OE is

An administrator could also add the string "\n\nend\n\n" to the
mailing list end text. That might cause OE to stop interpreting the
message body as a UUE attachment when this bug gets tickled.

But consider: the more we cover this up server side, the less pressure
there is on MS to clean up the brain damaged code in OE.

 John Hardin KA7OHZ    ICQ#15735746    http://www.impsec.org/~jhardin/
 jhardin at impsec.org                       pgpk -a jhardin at wolfenet.com
  768: 0x41EA94F5 - A3 0C 5B C2 EF 0D 2C E5  E9 BF C8 33 A7 A9 CE 76 
 1024: 0xB8732E79 - 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
  In 1998 more than three times as many people in the US were killed
  by incompetent physicians than were killed by handguns, yet the
  President of the A.M.A. is adopting "gun safety" as his platform.
   995 days until the Presidential Election

More information about the esd-l mailing list