[ Docs | Tools | Advisories | Full-Disclosure ]
DoS in popclient 3.0b6 ---------------------- Release Date: 29th June 2004 Discovery: Dean White <incidents@oneguard.com> Research: John Cartwright <johnc@grok.org.uk> Overview -------- "popclient is a Post Office Protocol compliant mail retrieval client which supports both POP2 (as specified in RFC 937) and POP3 (RFC 1725)." An off-by-one condition exists in the POP3 handler code present in this application. By crafting a malicious email a remote attacker may cause a denial of service against users of this software. Detail ------ The problem occurs in pop3.c, function 'POP3_readmsg': int POP3_readmsg (socket,mboxfd,topipe) int socket; int mboxfd; int topipe; { [1] char buf [MSGBUFSIZE]; char *bufp; char savec; char fromBuf[MSGBUFSIZE]; int needFrom; int lines,sizeticker; time_t now; /* This keeps the retrieved message count for display purposes */ static int msgnum = 0; /* set up for status message if outlevel allows it */ if (outlevel > O_SILENT && outlevel < O_VERBOSE) { fprintf(stderr,"reading message %d",++msgnum); /* won't do the '...' if retrieved messages are being sent to stdout */ if (mboxfd == 1) fputs(".\n",stderr); else ; } else ; /* read the message content from the server */ lines = 0; sizeticker = MSGBUFSIZE; while (1) { [2] if (SockGets(socket,buf,sizeof(buf)) < 0) return(PS_SOCKET); bufp = buf; if (*bufp == '.') { bufp++; if (*bufp == 0) break; /* end of message */ } [3] strcat(bufp,"\n"); A buffer of size MSGBUFSIZE is declared at [1]. At [2], the function SockGets is called, which returns a line of input from the message into this buffer. In the case of a long line, this will return at maximum a string of (MSGBUFSIZE - 1) characters plus the null terminator required. In this case, then the strcat is performed at [3], the null is overwritten with the '\n' character, and a new null is placed one byte after the buffer, partially overwriting the saved stack pointer. When the function returns this leads to an application crash, however there does not appear to be any possibility of influencing this behaviour to cause anything other than a DoS. Workaround ---------- The call to SockGets at [2] should use (sizeof(buf)-1) for the third parameter so that bounds are not overrun when the newline is applied. Notes ----- - Whilst symptoms of this problem were discussed as far back as 1998, there does not appear to be any (publicly available) research into, or fix for, this DoS. - popclient 3.0b6 code was sourced from the OpenBSD ports tree. - Thanks to Len Rose/Netsys.com for the continued long-time support! This advisory will be archived at http://www.grok.org.uk/advisories/popclient.html