ms.outlook.DoS.txt

`Date: Fri, 25 Jun 1999 13:24:02 -0700  
From: YoDuh <[email protected]>  
To: [email protected]  
Subject: Outlook denial of service  
  
I've found a problem in qualcomm popper (and presumabley others) in that it  
doesn't check for an existing X-UIDL: headers, but simpley uses it when the  
client sends in a uidl request. This problem can manifest itself as an  
effective denial of service attack against microsoft outlook clients  
because outlook looks for unique uidl's for each message and if there are  
duplicates it will hang prior to downloading any mail. I've put up a small  
web site detailing the problem and some possible work arounds/fixes at  
  
http://getaclue.org/yoduh/outlook.html  
  
------------------------------------------------------------------------------  
  
<http://getaclue.org/yoduh/outlook.html>  
  
YoDuh's Stupid Outlook Bug  
[email protected]   
  
I (obviously) don't use outlook, but a customer called in with a problem   
and I managed to narrow it down to this. The instance where I found this   
in the wild was with a couple of spam messages, so someone has a broken   
spam mailer (suprise).   
  
Affected clients: All known versions of outlook (I specifically tested:   
Outlook Express, Outlook 97, Outlook 98, Outlook 2000 and I applied   
appropriate service packs with no change in behavior). Other mail clients   
seem to handle this more intelligently (Netscape, and Eudora light at   
least are unaffected). It is possible that some clients will handle this   
differently (ie: skipping messages, etc..), but that is unverified. If   
anyone finds any other clients that are affected let me know.   
  
Synopsis: MUA's use a messages uidl as part of a pop transaction to check   
whether they have received the message before (most include other checks   
also). Usually the field is calculated when the message is first read by   
the popper. A lot of poppers will store the uidl for that message in an   
X-UIDL: header to avoid having to recalculate it every time the client   
checks thier e-mail. However, mail messages may arrive into a mailbox with   
a predefined X-UIDL: header. Most popper daemons will use this header   
instead of calculating a new header. If two messages arrive with the same   
(duplicate) X-UIDL: header outlook will freak on the initial negotiation   
where is sends a uidl command to the pop server. Most of the time Outlook   
will simply stop all activity at that point and you won't be able to   
download anything, very rarely (one in about 20 tries) it will give you an   
error and then let you continue the download.   
  
Sample broken mail box (on sendmail/popper system).   
---------------------------------------------------  
From [email protected] Wed Apr 21 11:40:55 1999  
X-UIDL: 10293287_192832.222  
Date: Mon, 14 Jun 1999 14:39:34 -0400  
From: [email protected]  
Subject: test 30  
To: [email protected]  
  
Test 30  
  
From [email protected] Wed Apr 21 11:40:55 1999  
X-UIDL: 10293287_192832.222  
Date: Mon, 14 Jun 1999 14:39:34 -0400  
From: [email protected]  
Subject: test 31  
To: [email protected]  
  
Test 31  
  
Notice the duplicate X-UIDL headers, the messages don't have to be   
contiguous (as shown here), and normally a mail file will have a lot more   
headers in it (duh).   
  
  
Diffs to qpopper to ignore the stored UID's.   
--------------------------------------------  
*** ../qpopper2.53.orig/pop_dropcopy.c Thu Jul 9 16:44:07 1998  
--- pop_dropcopy.c Tue Jun 22 12:11:47 1999  
***************  
*** 412,417 ****  
--- 412,418 ----  
}  
  
if (inheader) {  
+ pop_log(p,POP_DEBUG, "HEADER: %s", buffer);  
if (*buffer == '\n') {  
inheader = 0;  
content_length = cont_len;  
***************  
*** 429,434 ****  
--- 430,440 ----  
*cp++ = '\n';  
*cp = '\0';  
  
+ #ifdef DEBUG  
+ if(p->debug)  
+ pop_log(p,POP_DEBUG, "Msg %d generated UID %s", mp->number, cp);  
+ #endif  
+   
mp->length += strlen("X-UIDL: ") + strlen(mp->uidl_str) + 1;  
p->drop_size += strlen("X-UIDL: ") + strlen(mp->uidl_str)+1;  
  
***************  
*** 457,462 ****  
--- 463,469 ----  
int len;  
  
/* Skip over header string */  
+ /*  
cp = &buffer[7];  
while (*cp && (*cp == ' ' || *cp == '\t')) cp++;  
if( (len = strlen(cp)) > MIN_UIDL_LENGTH && len < MAX_UIDL_LENGTH ) {  
***************  
*** 465,470 ****  
--- 472,478 ----  
mp->length += nchar + 1;  
p->drop_size += nchar + 1;  
}  
+ */  
}  
continue; /* Do not include this value in the message size */  
} else if ((strncasecmp(buffer,"Status:",7) == 0)) {  
***************  
*** 691,699 ****  
--- 699,710 ----  
int len;  
char *cp;  
  
+ /*  
uidl_found++;  
+ */  
  
/* Skip over header */  
+ /*  
cp = &buffer[7];  
while (*cp && (*cp == ' ' || *cp == '\t')) cp++;  
if( (len = strlen(cp)) > MIN_UIDL_LENGTH && len < MAX_UIDL_LENGTH ) {  
***************  
*** 702,707 ****  
--- 713,719 ----  
mp->length += nchar + 1;  
p->drop_size += nchar + 1;  
}  
+ */  
}  
continue; /* Do not include this value in the message size */  
} else if (!strncasecmp(buffer,"Status:",7)) {  
  
  
This is sort of a broken way to handle it, properly qpopper should be   
smarter about checking for duplicates in the file, or comparing a   
calculated UID against the stored one (although that defeats the purpose   
of storing it in the first place). Applying this patch may result in an   
increased load on busy mail servers as they will have to recalculate the   
uidl for each message every time the client accesses it. I'm sure that   
there are a lot of other (better) ways to solve it.   
  
If you can't patch your popper you can fix the offending mailbox by simply   
stripping X-UIDL: headers from the mailbox   
(something like "grep -v ^X-UIDL:" mailbox > mailbox.tmp; mv mailbox.tmp mailbox"   
should work in most cases).   
  
Being unable (and unwilling even if I did have it) to hack M$ code, and to   
lazy to patch any other pop daemons than qpopper, thats all the fixes I   
have for now. If anyone actually writes something for any other pop   
daemons or better patches for the above let me know & I'll link them here   
(with credit if desired).   
`