Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
>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!
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |