COMMAND
qpopper
SYSTEMS AFFECTED
qpopper 3.0 fc2, qpopper 2.53....
PROBLEM
3APA3A found following. Malicious user can remotely post
message with spoofed or incorrect headers (including "Received:"
one) and in some cases bypass virus checking. This can be used
for sending trojans or to attack vulnerabilities in MUA.
In most unix systems e-mail delivered to user is usually stored
in his mailbox, which has predefined format (so-called "unix
mailbox" or "berkley mailbox"). This mailbox holds messages in
plain format separated by empty line ("\n") and specially formed
"From " header. The pattern of the next message in mailbox is
"\n\nForm ".
Then local mail programs (f.e. mail.local) delivers message to
user's mailbox it searches for this pattern and if message
contains one "From" will be commented out by '>' and additional
'\n' will be added to message if necessary. This assumes mailbox
integrity and protects from e-mail spoofing.
qpopper has vulnerability which allows for malicious user to
generate his own "From" with followed email headers and text.
The problem is in the way qpopper reads data from mailbox. Qpopper
uses fgets() or fgets()-like routine, mfgets(), which reads data
from mailbox into the fixed 1024 byte buffer and returns string in
case either '\n' character received or 1023 bytes read. Malicious
user can put text like (without leading spaces):
AAAA...AAA(string of 1023 symbols)\n
From user Wed Dec 2 05:53 -0700 1992
In this case fgets() will return 3 strings:
"AAAA...AAA(string of 1023)symbols", without '\n',
"\n",
"From user Wed Dec 2 05:53 -0700 1992"
and this will be recognized as a beginning of the new message in
the mailbox.
Text after "From " string will be recognized as a headers and text
of the next message, allowing to generate any headers and text.
Additionally, this "internal" messages will be treated by any
software as a plain text inside message, without any MIME
attachments. This allows to bypass virus checking in case
antiviral tools scans only attached files.
mail.local also uses fgets() for reading input message, but
default buffer size is 2048, so "From " will not be commented
and problem can be exploited. If another local mailer is used
with same behavior and buffer size 1024 or mailer splits strings
of 1024 bytes this problem couldn't be exploited.
SOLUTION
Vendor contacted, bug scheduled to be patched in next release,
FreeBSD port patched. Possible temporary fix for qpopper 3.0 fc2
(not tested):
--- pop_dropcopy.c Sat Mar 18 02:31:11 2000
+++ pop_dropcopy.c Wed Apr 12 18:11:11 2000
@@ -205,6 +205,8 @@
int newline = 1;
+int isbreaked = 0;
+int wasbreaked = 0;
/*
* 0 for not a from line
@@ -229,6 +231,14 @@
/* If the previous line was not a newline then just return */
/* From message separators are preceeded by a newline */
+ if (isbreaked) {
+ wasbreaked = 1;
+ return ( 0 );
+ }
+ if (wasbreaked) {
+ wasbreaked = 0;
+ return ( 0 );
+ }
if ( *cp == '\n' ) {
newline = 1;
return ( 0 );
@@ -1593,9 +1603,13 @@
if( size <= 0 ) {
return NULL;
}
+ isbreaked = 1;
while( --size && ((c = getc(stream)) != EOF) ) {
if( (*p = (char)c) == '\0' ) *p = ' ';
- if( *p++ == '\n' ) break;
+ if( *p++ == '\n' ) {
+ isbreaked = 0;
+ break;
+ }
}
if( p == s ) return NULL;
*p = '\0';
This problem has been fixed in Qpopper 3.0.1b2, which is now
available. Note that the problem does not occur on Solaris
systems (which use Content-Length), nor on systems which use
mail or certain other local delivery agents. Also, note that the
patch supplied above may not function correctly and may cause
messages to not be recognized.