Closed Bug 373973 (CVE-2007-1558) Opened 13 years ago Closed 13 years ago

Security vulnerability in APOP authentication


(MailNews Core :: Networking: POP, defect)

Not set


(Not tracked)



(Reporter: dveditz, Assigned: ch.ey)



(Keywords: fixed1.8.0.12, fixed1.8.1.4, Whiteboard: [sg:moderate] public paper to be presented March 28)


(1 file, 4 obsolete files)

mail sent to
- - - - - - - - - - - - - - - - - -

I found a security vulnerability in the APOP authentication.  It is
related to recent collision attacks by Wang and al. against MD5.  The
basic idea is to craft a pair of message-ids that will collide in the
APOP hash if the password begins in a specified way.  So the attacker
would impersonate a POP server, and send these msg-id; the client will
return the hash, and the attacker can learn some password characters.

The msg-ids will be generated from a MD5 collision: if you have two
colliding messages for MD5 "<????@????>x" and "<¿¿¿¿@¿¿¿¿>x", and the
message are of length two blocks, then you will use "<????@????>" and
"<¿¿¿¿@¿¿¿¿>" as msg-ids.  When the client computes MD5(msg-id||passwd)
with these two, it will collide if the first password character if 'x',
no matter what is next (since we are at a block boundary, and the end of
the password will be the same in the two hashs).  Therefore you can
learn the password characters one by one (actually you can only recover
three of them, due to the way MD5 collisions are computed).

This attack is really a practical one: it needs about an hour of
computation and a few hundred authentications from the client, and can
recover three password characters.  I tested it against Thunderbird, and
it does work.

However, using the current techniques available to attack MD5, the
msg-ids sent by the server can easily be distinguished from genuine ones
as they will not respect the RFC specification.  In particular, they
will contain non-ASCII characters.  Therefore, as a security
countermeasure, I think Thunderbird (and other Mozilla derived mail
client) should reject msg-ids that does not conform to the RFC.

The details of the attack and the new results against MD5 needed to
build it will be presented in the Fast Software Encryption conference on
March 28.  I can send you some more details if needed.

Meanwhile, feel free to alert any one that you believe is concerned.
I am already sending this mail to the maintainers of Thunderbird,
Evolution, fetchmail, and mutt.  KMail already seems to do enough checks
on the msg-id to avoid the attack.

-- Gaëtan LEURENT
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.4?
Flags: blocking1.8.0.12?
Flags: blocking-thunderbird2?
Whiteboard: public paper to be presented March 28
So if I understand that right in order to prevent the current attack, it would be sufficient to check if nsCRT::IsAscii(m_ApopTimestamp.get()) is true.
I'd nevertheless like to make sure the timestamp really conforms the RFC. I'm currently looking if a function for such a check already exists in the Mozilla code.
Scott: blocking status on this one is your call.
Attached patch proposed patch (obsolete) — Splinter Review
I couldn't find an existing code in Mozilla so I wrote a routine to test for RFC compliance.
I don't really like the resulting code, but it works. Any other approach or critics to improve that routine is welcome.

Is a fairly good PCRE engine available in Mozilla (outside JS)?
Wow, thx, Christian. But there's a lot not to love about the resulting code - I'd strongly consider the nsCRT::IsAscii check first...

I don't know if there's a PCRE engine or anything similar in Mozilla, outside of js
> I'd strongly consider the nsCRT::IsAscii check first

You're right, that surely is a good idea.

For the rest - how to make the best of a bad job (what's the worst)? I'd like using string classed with iterators and something more robust. But I don't know how to look at the previous/next char with them.
Cleaned it up a bit and fixed two bugs but that doesn't make a beauty of it. So I'll wait for comments.
Presuming this should block the next set of releases.
Assignee: nobody → ch.ey
Flags: blocking1.8.1.4?
Flags: blocking1.8.1.4+
Flags: blocking1.8.0.12?
Flags: blocking1.8.0.12+
Attached patch updated patch (obsolete) — Splinter Review
Not nicer and even more tests. Previously I ignored that there might be more than one < or > respectively in the greeting.
E.g. this is a possible greeting
+OK my own POP3 > <fake@ü.org> server: <"x{"@[ne\ t]>, that was the msg-id<>.
but only <"x{"@[ne\ t]> is a valid msg-id. That means nothing outside the new routine can determine which part actually contains the timestamp - and so no IsAscii test can be performed before calling findCompliantMsgId() (and doesn't make sense afterwards).
Attachment #258830 - Attachment is obsolete: true
By the way, Mozilla does not offer a way for the user to ask for a strong authentication.  The user can only select "secure authentication" but the protocol is then autodetected when connecting to the server.  Therefore, is a user is using "secure authentication", the attacker would pretend to only support APOP, and will be able to recover the password, without any warning to the user.  It would be better to have a way for the user to say "I know that my server support CRAM-MD5, please use it or warn me".  Or maybe Mozilla could remember the authentication mode it used the last time and warn the user if it is no longer supported.
Yes, that's a wish expressed from time to time. On the other hand people argue that will make usage to complicated. It mainly is a question of UI, not implementation.
Christian, in the real world, it seems to me server greetings are not going to sprinkle things that look like msg-ids all over. Seems to me that scanning backwards from the end for a <> delimited msg-id is going to be fine, and checking the string inside that for ascii (and a '@') would be sufficient. Given that many clients weren't handling this correctly before, that argues that servers weren't generating multiple things in the greeting that looked like msg-ids, and counting on the client to pick out the one that was a legal msg-id.

So the algorithm might be:

1. Scan from the end of the greeting for a <> delimited msg-id, ascii and containing a '@', 

2. Loop until we find a legal msg-id or get to the beginning of the line.

'<' and '>' aren't legal characters in msg-ids, right, and they're not escaped, so this should be fairly simple. Or am I missing something?
David, you're right that it's very unlikely normal servers greetings are going to look like my example. My desire was to not only prevent current attacks by malicious servers but also set the highest hurdle possible for any future attacks.

< and > are legal on left as well on right side of a msg-id as long as those sides consist of a no-fold-quote or no-fold-literal, i.e. "xxx" resp. [xxx].
I don't know how common this is or if it's used at all.

Ignoring this, implementing the algorithm you proposed is fairly simple. I'd be even simpler if I knew how to do a search from right in Mozilla string objects.
Christian, look for RFind.
Attached patch patch with simple validity-check (obsolete) — Splinter Review
Thanks David.
That patch should do the trick. With this procedure > always terminates a msg-id but < can occur within it (e.g. <xx<x@xx>). That's not valid but the test is cheap.

I only hope I didn't make the ascii-check stuff more complicated than necessary.
Attachment #259195 - Attachment is obsolete: true
Attachment #260484 - Flags: review?(bienvenu)
Comment on attachment 260484 [details] [diff] [review]
patch with simple validity-check

Christian, thx for doing this! - it looks OK. Is there any reason not to put this code in nsPop3Protocol.cpp? Is any other code likely to care about APOP?
Uhm yes you're right. I just had put it there without much thinking. It'd be better in nsPop3Protocol.cpp.
I can do this tomorrow.
Attached patch simple check 2 (obsolete) — Splinter Review
Moved getApopTimestamp into nsPop3Protocol and simplified it a bit more by using the member variables directly.
Attachment #260484 - Attachment is obsolete: true
Attachment #260484 - Flags: review?(bienvenu)
Comment on attachment 261783 [details] [diff] [review]
simple check 2

looks good, thx, Christian. I'll probably change it to GetApop instead of getApop and change the while (1) to while (PR_TRUE) before landing...
Attachment #261783 - Flags: superreview+
Attachment #261783 - Flags: review+
this is what I landed on the trunk - I just made the changes I described earlier...
Attachment #261783 - Attachment is obsolete: true
Comment on attachment 261808 [details] [diff] [review]
fix landed on trunk.

requesting approval for 1.8.1 branch.
Attachment #261808 - Flags: approval1.8.1.4?
fixed on trunk
Closed: 13 years ago
Resolution: --- → FIXED
Version: 1.8 Branch → Trunk
Wouldn't we want this on the 1.8.0 branch for Thunderbird 1.5.0.something too?

I'll let mscott deal with the 1.8.1 approval for this. Not sure we're shipping a tbird based on, might wait until
Comment on attachment 261808 [details] [diff] [review]
fix landed on trunk.

yes, you're right - we'd want this for the next 1.5 release...
Attachment #261808 - Flags: approval1.8.0.12?
Comment on attachment 261808 [details] [diff] [review]
fix landed on trunk.

approved for and, a=dveditz for release-drivers
Attachment #261808 - Flags: approval1.8.1.4?
Attachment #261808 - Flags: approval1.8.1.4+
Attachment #261808 - Flags: approval1.8.0.12?
Attachment #261808 - Flags: approval1.8.0.12+
fixed on 1.8.0 and 1.8.1 branches
Whiteboard: public paper to be presented March 28 → [sg:low] public paper to be presented March 28
For future reference:

Gaëtan presented at FSE March 28 (as he said)

And posted to BUGTRAQ about it April 2

Both of the above link to slides of his talk.

Another group presented something very similar as a Rump talk at the same conference, which got filed as bug 378113.

In the second set of slides they claim to have extended the attack to 31 password characters
Alias: CVE-2007-1558
Group: security
Duplicate of this bug: 378113
raising severity to "sg:moderate" based on the longer password claim (comment 27)
Whiteboard: [sg:low] public paper to be presented March 28 → [sg:moderate] public paper to be presented March 28
Christian, Gaëtan, are there any steps to reproduce or a testcase for this bug that i can run to verify fixed this bug ?
Flags: blocking-thunderbird2?
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.