373973 - (CVE-2007-1558) Security vulnerability in APOP authentication

Status: RESOLVED FIXED

(MailNews Core :: Networking: POP, defect)

Description

[Daniel Veditz [:dveditz]]

mail sent to [e-mail]:
- - - - - - - - - - - - - - - - - -
Hello,

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

Comment 1

[Christian Eyrich]

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.

Comment 2

[Daniel Veditz [:dveditz]]

Scott: blocking status on this one is your call.

Comment 3

[Christian Eyrich]

Attachment: proposed patch

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)?

Comment 4

[David :Bienvenu]

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

Comment 5

[Christian Eyrich]

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

Comment 6

[Christian Eyrich]

Cleaned it up a bit and fixed two bugs but that doesn't make a beauty of it. So I'll wait for comments.

Comment 7

[Daniel Veditz [:dveditz]]

Presuming this should block the next set of releases.

Comment 8

[Christian Eyrich]

Attachment: updated patch

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

Comment 9

[Gaëtan LEURENT]

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.

Comment 10

[Christian Eyrich]

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.

Comment 11

[David :Bienvenu]

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?

Comment 12

[Christian Eyrich]

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.

Comment 13

[David :Bienvenu]

Christian, look for RFind.

Comment 14

[Christian Eyrich]

Attachment: patch with simple validity-check

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.

Comment 15

[David :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?

Comment 16

[Christian Eyrich]

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.

Comment 17

[David :Bienvenu]

great,thx!

Comment 18

[Christian Eyrich]

Attachment: simple check 2

Moved getApopTimestamp into nsPop3Protocol and simplified it a bit more by using the member variables directly.

Comment 19

[David :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...

Comment 20

[David :Bienvenu]

Attachment: fix landed on trunk.

this is what I landed on the trunk - I just made the changes I described earlier...

Comment 21

[David :Bienvenu]

Comment on attachment 261808 [details] [diff] [review]
fix landed on trunk.

requesting approval for 1.8.1 branch.

Comment 22

[David :Bienvenu]

fixed on trunk

Comment 23

[Daniel Veditz [:dveditz]]

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 1.8.1.4, might wait until 1.8.1.5

Comment 24

[David :Bienvenu]

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

Comment 25

[Daniel Veditz [:dveditz]]

Comment on attachment 261808 [details] [diff] [review]
fix landed on trunk.

approved for 1.8.0.12 and 1.8.1.4, a=dveditz for release-drivers

Comment 26

[David :Bienvenu]

fixed on 1.8.0 and 1.8.1 branches

Comment 27

[Daniel Veditz [:dveditz]]

For future reference:

Gaëtan presented at FSE March 28 (as he said)
http://fse2007.uni.lu/video.html

And posted to BUGTRAQ about it April 2
http://www.securityfocus.com/archive/1/464477/30/0/threaded

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.
  http://fse2007.uni.lu/slides/rump/md5.pdf
  http://fse2007.uni.lu/slides/rump/apop.pdf

In the second set of slides they claim to have extended the attack to 31 password characters

Comment 29

[Daniel Veditz [:dveditz]]

raising severity to "sg:moderate" based on the longer password claim (comment 27)

Comment 30

[Carsten Book [:Tomcat]]

Christian, Gaëtan, are there any steps to reproduce or a testcase for this bug that i can run to verify fixed this bug ?