It seems that security problems come along, like buses, in clumps. The latest is cutely called POODLE but, unlike Heartbleed and Shellshock, this is of a very different nature.

What was interesting about Heatbleed and Shellshock is that they are caused by stupid mistakes. In the case of Heatbleed, the programmer simply didn't check that the request to echo back data didn't ask for more data than was sent. It was essentially a forced buffer overrun problem, which is a mistake we have been making since the start of programming.

The Shellshock problem was just as "traditional" a programming error. The problem was that, in determining what constituted a dynamically defined function, code was executed during the definition and that code could be added to by an attacker. It's the old -"don't let the outside world give you code to execute" problem.

What was worrying about both these programming errors is that they were easy to understand and easy to make use of. As a result just about anyone could put together code that exploited them in almost no time at all - they were basically open doors. 

Now we come to POODLE and this isn't as such a simple programming error. This one smacks of real crypto.  It was discovered by three Googlers and revealed in the Online Security Blog. 

There are two components to the attack. The first is a simple downgrade of the encryption being used to one that is vulnerable. TLS is the up-to-date encryption method used for most secure HTTP. But in order to work with older servers the client can negotiate down to the older SSL 3.0 protocol. This is done so that the web goes on working with older technology, but it also means that the newer TLS protocol is really only secure in practice as the older SSL 3.0 - and this is known not to be the best design possible. 

This gives us the final three letters of POODLE - Downgraded Legacy Encryption. 

The second part of the attack makes use of a deficiency in the RC4 cipher which SSL 3.0 uses. The block cipher makes use of padding to create an integral number of blocks. The problem is that the padding is arbitrary and not covered by the Message Authentication Code (MAC). This allows an attacker to change padding and have the server attempt to decode the message. 

Of course, to change the padding the attacker has to be a "man-in-the-middle" able to intercept data packets going from the client, change them and forward them on to the server as if they had come from the client. This in itself is quite difficult to achieve and so moves the attack from the "easy" category into "quite hard really".

The actual attack also makes use of the fact that a block with L bytes of padding always ends with a byte of value L-1. If a message contains a complete block of padding at the end and if this is replaced by an encrypted block from a previous message in the same stream then the server will accept the entire message if the decrypted block XORed with the previous block has L-1 as its final value - the rest of the block is just supposed to be padding and so the server doesn't care what it is. 

Most of the time the server will reject the message, but on average once in 256 requests things will work out right and the server will accept the message and the attacker know the value of the last byte in the block. 

This gives us the first letters of POODLE which is now revealed to mean Padding Oracle On Downgraded Legacy Encryption.

By shifting the message around the attacker can decode each byte by placing it at the end of the padding block.

The solutions offered are basically to disable SSL 3.0 and this is what Google has done, for example. 

However, this is not an "open door" security vulnerability. Building attack code that used Heartbeat or Shellshock wasn't rocket science POODLE is more like rocket science. It also requires a successful man-in-the-middle attack which, as Craig Young, security researcher at Tripwire confirms isn't easy either:

"In general, an attacker needs to already have considerable control over the victim client and the network connecting the victim to the server.  In this controlled environment, an adversary can manipulate SSL records and use the server's response to indicate whether the message was readable.  With each time the server accepts the message, the attacker can decrypt another byte from a specific location in the request.  By controlling the request path and body, it would take no more than 256 manipulation attempts for each byte the attacker wants to decrypt.  This attack is ideal for hijacking authenticated HTTP sessions although it is not likely that anyone other than a national spy agency or telecom provider would have the means to carry out the attack."

 
Photo credit: B. Schoener

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info