Category: Security

Clench is inferior to TLS+SRP

~ Nate Lawson ~ 21 Comments

There’s a new proposed client authentication method called Clench from web security super-group Goatse Security. While their deep magic may work for revealing iPad email addresses, it’s not so great when it comes to designing crypto protocols.

This protocol is intended to provide a way for clients to authenticate themselves to servers and vice versa without revealing useful information to a man-in-the-middle. While most of the rhetoric in the post is anti-PKI (and rightly so), their protocol doesn’t really replace PKI.

First, it only works for sessions where the user is logging in. There is no way to authenticate just the server (anonymous client). This means the protocol does not replace PKI since it assumes a priori that the server knows the client’s password. There has to be an existing relationship established with this particular server before Clench can be used. This is the chicken-and-egg problem that SSL+certs solves by including a root cert in the browser.

Second, the server has to store plaintext passwords. The authors attempt to explain this away by suggesting the password will be stored in some other secure device (like an HSM). But this is definitely a step down in security from appropriate password hashing methods like bcrypt.

Finally, the authors don’t emphasize that Clench will require changes to all client software (e.g., your web browser). This has been a non-starter for many protocols.

Luckily, all of this has already been solved. SRP is a family of password-based authentication schemes. SRP provides the following:

  • Provably secure against dictionary attacks
  • Provably secure against an active man-in-the-middle attacker
  • No trusted third-party required
  • Passwords stored on the server are salted and hashed

SRP has been around since about 1998. RFC 5054 added a TLS extension for SRP and was approved in 2007. OpenSSL will support it in version 1.0.1. Various patches are out for OpenSSH support.

All the discussion about Clench will hopefully raise awareness of SRP instead. It’s been around for 12 years, solves more problems, and has none of the drawbacks Clench has. It’s definitely time to adopt SRP.

More details surface on PS Jailbreak

~ Nate Lawson ~ 4 Comments

There have been a few new developments regarding the recent PS3 USB exploit. Working with impressive speed, Mathieulh and other developers have released an open-source version of the exploit called PS Groove. A much more detailed analysis of PS Jailbreak was also posted, although it is still not completely clear how the exploit works.

The PS Groove exploit uses an AT90USB board with the excellent LUFA library as I had expected. (By the way, send some donations to Dean Camera if you use that library. He’s a generous developer.) It attaches the proper config descriptors in the right order but contains a different payload. It will also allow you to disconnect the USB device after the exploit is complete.

Now that more details are public, the exploit is quite impressive. It is a heap overflow, not stack overflow as Gamefreax had suggested. Also, I was right that they had misread the descriptor lengths (0x4D vs. 0xAD).

The exploit involves using various config/interface descriptors to align shellcode on the heap. Then through some still-unknown mechanism, a heap overflow gives a user-controllable function pointer, which is later called after free(). The bug appears to be related to how the PS3 enumerates Sony’s internal test JIG device. This device may be probed by a different portion of the kernel, which trusts the device’s USB descriptors more.

Go check out the code and read the analysis. I’d love to hear more about how this exploit works and how it was discovered.

Theories of how PS Jailbreak works

~ Nate Lawson ~ 7 Comments

A company recently announced a modchip for the PS3 and claims they will be shipping them soon. It plugs into the USB port and allows running backup games. Inside the device is an ATmega8U2 USB microcontroller, something I’ve worked with before. While I didn’t have access to this device and don’t know PS3 internals, I spent a few minutes looking at a hex dump from a USB trace.

An article on Gamefreax (German, alternate in English) claimed to have reverse-engineered this device. They believe that a stack overflow in USB config descriptor processing allows the device to execute code on the PS3 host. However, their page shows a useless set of packets from a USB trace and some hex code obscured with a logo so it’s not possible to verify their claims from the info given.

In a later comment, a user named Descrambler posted a more complete dump of hex data from the USB trace. It is still not fully complete, but it’s enough to look into more of the details.

The first trace starts with a standard configuration descriptor. It is followed by a relatively standard interface descriptor, except it is class 254, subclass 1, and protocol 2. Since this is in the reserved class range, perhaps this is related to an internal Sony test tool. Following this descriptor is some data and PowerPC code.

The second trace starts with a config descriptor that is a bit weird. It claims the total length is 77 bytes (68 bytes of interface descriptors after the 9-byte config descriptor). It also claims to support 10 interfaces. With the standard interface descriptor length of 9 bytes, the total length should be 99 bytes.

There are multiple ways this might affect the PS3. If it believes the total length field for sizing the buffer, the first bytes after the initial 77 could overflow a buffer (in this case, “00 00 fe 01 02 00 09 04” are what follows). Or it might simply copy it into a static buffer (if 256 bytes long, the first bytes to overflow would be “fe 01 02 00 09 04 00 00”).

If it’s not an overflow, it could be related to how the PS3 parses the first 10 interface descriptors. The sequence is not regular. Taken in 9-byte chunks, it diverges after the first 6 interface descriptors, giving a next descriptor of “09 00 09 04 00 00 00 fe 01”. This is not a valid descriptor. Or, if the PS3 parses lengths of descriptors, it will end up with a few very short ones (“02 00”).

These are all just theories. It’s quite possible the second trace is just a decoy, meant to slow down reversing. The behavior described by Gamefreax cannot be validated from the USB traces posted by Descrambler. It appears Gamefreax may have misread the trace (77 bytes in the second trace is 0x4d, but they claim a descriptor length is 0xAD). Also, Descrambler’s hex dumps are incomplete and don’t show the various phases described in the Gamefreax post.

It’s definitely too early to claim that the PS Jailbreak exploit has been reverse-engineered. However, it should be quite easy to clone since all the data needed to do so is present in a USB trace. Just paste the data into example code for an AT90USB and replay the same descriptors. You might have to add in a bus disconnect in the right place but it should be relatively simple.

Crypto 2010 rump session

~ Nate Lawson ~ 2 Comments

One of the leading indicators of upcoming advances in cryptography is the rump session at the CRYPTO conference. Speakers are given 3 minutes to introduce works in progress or crack jokes. For example, I remember Paul Kocher’s groundbreaking presentation on extremely low exponent RSA (e=1). Here is more history of this casual, but important, event each year.

This year’s session had some interesting talks, mostly about SHA-3 hash candidates. Dinur and Shamir announced an algebraic attack on Hamsi-256, which has had other attacks announced previously. They also attacked the Grain-128 stream cipher. Leurent spoke about distinguishing attacks and whether a hash function can remain secure even when the underlying compression function has efficient distinguishers.

Cohn and Heninger presented a survey of applications of Coppersmith’s theorem, which has many uses beyond cryptanalysis of public key systems. There was a lot of interest in making public key systems resilient in the face of leakage (e.g., via side channels). This is good since traditional (EC)DSA falls apart if the nonce is even partially predictable. A presentation on noisy Diffie-Hellman looked interesting, although the applications are unclear to me.

On the implementation front, Mroczkowski described a fast implementation of Trivium in Python. It used the CorePy library to generate SSE3 instructions. This was to optimize the cube attack previously announced by Dinur and Shamir in 2008.

And finally, the humorous CFP for the Journal of Craptology was a great way to end. What were your favorite rump session talks?