Date: Fri, 25 Jun 1999 13:24:02 -0700
From: YoDuh <yoduh@GETACLUE.ORG>
To: BUGTRAQ@netspace.org
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
yoduh@getaclue.org
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 yoduh@getaclue.org Wed Apr 21 11:40:55 1999
X-UIDL: 10293287_192832.222
Date: Mon, 14 Jun 1999 14:39:34 -0400
From: yoduh@getaclue.org
Subject: test 30
To: hahaha@you.use.outlook.com
Test 30
From yoduh@getaclue.org Wed Apr 21 11:40:55 1999
X-UIDL: 10293287_192832.222
Date: Mon, 14 Jun 1999 14:39:34 -0400
From: yoduh@getaclue.org
Subject: test 31
To: hahaha@you.use.outlook.com
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).