FW: Oh, dear.....

[galster at mediaone.net (galster at mediaone.net)]

>From Risks-Digest:

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!