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

[Brett Glass]

Everyone:

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?

--Brett

-----------

Date: Mon, 28 Jan 2002 22:31:26 -0700 (MST)
From: Bear Giles <bear at coyotesong.com>
Subject: Yet another Microsoft Outlook exploit

Yet another Microsoft Outlook exploit is on the loose... and this time the
arrogance of the recommended solution is breathtaking.  The problem is the
built-in support for UUENCODED text within the body of a message.  Prudent
programmers will use a starting pattern such as

 "\n\nbegin ([[:octal:]]+) ([^\n]+)\n"

and subsequently verify that each line has the expected format.  Even
checking only the first few lines (e.g., verifying that the first character
correctly encodes the length of the rest of the line) essentially eliminates
any chance of a false hit.

Sadly, it will surprise few people that Microsoft cuts straight to the heart
of the matter.  If your line starts with "begin " (possibly with two
spaces), Outlook/Outlook Express WILL interpret the rest of the message as a
UUENCODED attachment.  It doesn't need a preceding blank line, nor a
following octal number.  It doesn't need subsequent lines that actually look
like UUENCODED data.

There are some reports on slashdot that later versions of O/OE have
discarded the "view source" command, with the effect that the rest of the
message is permanently lost to the user.  The use of this bug as a DOS
attack on mailing lists that use a 'digest' approach is left as an exercise
for the reader.

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!

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.  We, and by "we"
I mean every person on the planet who may ever send a message to an
O/OE <s>victim</s> user, or have a message forwarded to such users,
are advised (with editorial comments) to:

 * not start messages with the word "begin"

   (actually, it's *any* line starting with the word "begin".  And
   that's effectively a ban on the word "begin" for anyone using a
   mail agent with transparent line wrapping, e.g., the web mail
   portals that some ISPs are pushing.)

 * capitalize the word "begin," even when used within a sentence.  E.g.,
   "We will Begin the new project when Bob returns from his vacation.

 * Use a different word such as "start" or "commence."  E.g., all
   training materials for new Visual Basic programmers shall henceforce
   refer to "start/end" loops instead of "begin/end" loops.

Microsoft's justification for suggesting a significant change to the
English language instead of fixing their bug is given as:

  "In a SMTP e-mail message, a file attachment that is encoded in
  UUencode format is defined when the word "begin" is followed by
  two spaces and then some data,..."

Needless to say there is no citation given for this "fact."  That's probably
related to the fact that UUENCODE was defined by UUCP, not SMTP, and that
every encoder/decoder I have seen requires a leading blank line and a octal
file permissions code.

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!

Bear Giles