Academic attacks against RFC 1939, APOP (threat: quite minor)

["Bluefish (P.Magnusson)" <11a () GMX NET>]

Been inactive a while, too much work... Anyway it's 4:41, I couldn't sleep
so I started studdying cryptographic hashes (mainly BCRYPT) and suddenly I
came to think about an old POP3 source code I had to explain to some
friends a long time ago... I looked up the RFC, and I get the feeling it
does advocate for an unsecure usage of the cryptographic MD5 hash.

Have a look at
http://www.ietf.org/rfc/rfc1939.txt, Page 14 and beyond (APOP).

an authorization request is made in the following way:
      APOP name digest

The digest is a typical MD5(concat(salt,digest)), they do sugest the
following algorithm:

   digest <- MD5(contact(process-ID.clock@hostname,password))

Now look at their example:

         Examples:
             S: +OK POP3 server ready <1896.697170952 () dbc mtview ca us>
             C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
             S: +OK maildrop has 1 message (369 octets)

             In this example, the shared  secret  is  the  string  `tan-
             staaf'.  Hence, the MD5 algorithm is applied to the string

                <1896.697170952 () dbc mtview ca us>tanstaaf

             which produces a digest value of

                c4c9334bac560ecc979e58001b3e22fb

Now, the salt is server generated, thus according to the common
security norm, it should be generated by the "trusted computing base"
and as secure as your software. As long as no attacker gains control over
your TCB, you're safe, right?

I object. Pending on implementation, we have a couple of academic attacks
which actually may exists in some implementations (however I'm fairly sure
most POP3 implementations to be secure):

 1. Attacker monitors POP3 traffic using e.g. a sniffer.

 2. Asume PID to be constant (it isn't in most unix daemons, if it's
    always changing in all implementations, these attacks becomes academic
    only)

 3a. Clock changing too rarely, e.g once a second. Slow enough for
     attacker to spawn a new pop3 connection with the same
     process-ID.clock@hostname. Then as the real user supplies the
     solution to the MD5 digest, the attacker does so as well.

 3b. Attcker monitors the session, then after the the session is
     established attacker triest to maliciously modify the servers
     system clock by e.g. attack an NTP system used by the server.
     Successfull attacks on the system clock will allow attacker to
     spawn a new POP3 session with known digest
     for process-ID.clock@hostname & password.

Well. To sum this up, this is a pretty academic scenario. It assumes an
odd implementation which doesn't spawn children for authentication
(constant PID) and that the attacker wants a POP3 account when the
attacker simply could sniff the messages as the user downloads them.

But I thought it would be a good idea to bring this to attention so that
we don't end up with bad cryptography in other, more crucial, IETF
recommendations. Plus, RFC readers often assumes the standards to be
working solutions and may decide to use them in closed source applications
thus embeding vulnerabilities into new software.

Your system clock and your PID is *not* good PRNGs! In the case of POP3,
Linux' /dev/urandom is good enough, otherwise /dev/random is better for
crucial applications. Or use some other wellknown PRNG.

No offence to the RFC authors, you're work with the standard is much
appreciated and we've benefit from it a lot. However I do have some doubts
about the general idea with APOP. I'd recommend users who actually have a
mayor consern about POP3 security to put an encrypted wrapper around POP3
(like IPSec or a SSH tunnel) instead of trusting APOP to secure your mail
and/or mailaccount.

Also, you could look at http://www.ietf.org/rfc/rfc1734.txt
I'm not familiar with this specific technology, but as KERBEROS typically
is trusted, I assume this is far better than the sugested APOP scheme.

Good night folks!

..:::::::::::::::::::::::::::::::::::::::::::::::::..
     http://www.11a.nu || http://bluefish.11a.nu
    eleventh alliance development & security team

             http://www.eff.org/cafe