Bug 373973 (CVE-2007-1558)

Security vulnerability in APOP authentication

RESOLVED FIXED

Status

MailNews Core
Networking: POP
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: dveditz, Assigned: Christian Eyrich)

Tracking

({fixed1.8.0.12, fixed1.8.1.4})

Trunk
fixed1.8.0.12, fixed1.8.1.4
Bug Flags:
blocking1.8.1.4 +
wanted1.8.1.x +
blocking1.8.0.12 +
wanted1.8.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate] public paper to be presented March 28)

Attachments

(1 attachment, 4 obsolete attachments)

(Reporter)

Description

10 years ago
mail sent to security@mozilla.org:
- - - - - - - - - - - - - - - - - -
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
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.4?
Flags: blocking1.8.0.12?
Flags: blocking-thunderbird2?
(Reporter)

Updated

10 years ago
Whiteboard: public paper to be presented March 28
(Assignee)

Comment 1

10 years ago
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.
(Reporter)

Comment 2

10 years ago
Scott: blocking status on this one is your call.
(Assignee)

Comment 3

10 years ago
Created attachment 258830 [details] [diff] [review]
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

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

Comment 5

10 years ago
> 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.
(Assignee)

Comment 6

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

Comment 7

10 years ago
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+
(Assignee)

Comment 8

10 years ago
Created attachment 259195 [details] [diff] [review]
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).
Attachment #258830 - Attachment is obsolete: true

Comment 9

10 years ago
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.
(Assignee)

Comment 10

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

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

Comment 12

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

10 years ago
Christian, look for RFind.
(Assignee)

Comment 14

10 years ago
Created attachment 260484 [details] [diff] [review]
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.
Attachment #259195 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Attachment #260484 - Flags: review?(bienvenu)

Comment 15

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

Comment 16

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

10 years ago
great,thx!
(Assignee)

Comment 18

10 years ago
Created attachment 261783 [details] [diff] [review]
simple check 2

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 19

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

Comment 20

10 years ago
Created attachment 261808 [details] [diff] [review]
fix landed on trunk.

this is what I landed on the trunk - I just made the changes I described earlier...
Attachment #261783 - Attachment is obsolete: true

Comment 21

10 years ago
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?

Comment 22

10 years ago
fixed on trunk
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Version: 1.8 Branch → Trunk
(Reporter)

Comment 23

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

10 years ago
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?
(Reporter)

Comment 25

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

Comment 26

10 years ago
fixed on 1.8.0 and 1.8.1 branches
Keywords: fixed1.8.0.12, fixed1.8.1.4
(Reporter)

Updated

10 years ago
Whiteboard: public paper to be presented March 28 → [sg:low] public paper to be presented March 28
(Reporter)

Comment 27

10 years ago
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
Alias: CVE-2007-1558
Group: security
(Reporter)

Updated

10 years ago
Duplicate of this bug: 378113
(Reporter)

Comment 29

10 years ago
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 ?
(Reporter)

Updated

10 years ago
Flags: blocking-thunderbird2?
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.