Understanding POODLE | SUSE Communities

Understanding POODLE


Let’s take a closer look at the POODLE vulnerability that has been causing quite a stir during the last few days.

To begin with, it’s important to understand that POODLE is not a code vulnerability. It is a vulnerability of the SSL (Secure Socket Layer) protocol as specified.

Consequently, there is little that can be done about it in terms of code fixes. By and large, this is an issue of reviewing and possibly adjusting the security settings of network services that employ SSL for confidentiality.

However, in order to judge your exposure to the attack, it is good to understand more about how it works.

A general comment on cryptographic attacks

Cryptographers are a funny sort of people.

Picture a movie scene about someone trying to steal a tractor from a barn. In a Bruce Willis movie, you’d see Bruce smash the glass of a small window in the back of a barn, force his way through and climb into the tractor’s driver seat. He’d short circuit the ignition, and with roaring engine, he’d just drive it through the barn door, sending the splinters flying and yodeling “Yeehaw, Old McDonald – now I’ve got a TRACTOR!”

If you’re less of a Bruce Willis and more of a Tom Cruise person, your movie may be a bit different. Tom would probably enter the barn through an overhead window in the roof, and abseil himself with a funky contraption involving lots of colored wires. He would then use a SciFi gizmo to create 1024 clones of himself – and all these clones would quickly disassemble the tractor, packing up the pieces in clean white plastic crates, hundreds of which just happen to be neatly stacked along the barn walls, and shuttle the parts out of the little window in the back.

Many security vulnerabilities in software are usually exploited using a Bruce Willis type of attack. Straightforward, effective, and making one feel stupid for not having seen the problem before.

Attacks on cryptographic protocols, such as POODLE, often come with a lot of prerequisites that make them a little weird, like the Tom Cruise version pictured above. Even if it’s hard to imagine Tom Cruise starring in a film called Poodle. (Come to think of it, maybe it’s not that hard after all:)

After you’ve read through such a description, your first reaction may be, “Why should I worry about that? It sounds more likely that I’ll be hit by lightning!”

That may be true, actually. But on a number of levels, cryptography is about probabilities. If you encrypt data with a 128-bit key, you would expect that the only way for an attacker to get at your data is by brute force, i.e. by trying 2^128 different keys. Finding the right one within within the attacker’s life time is indeed much less likely than being hit by lightning.

However, when someone comes up with an attack that reduces the complexity of the problem to say trying 2^10 operations, that makes it significantly more likely to succeed. Even if the attack requires a convenient supply of white plastic crates. The attack may still not be very practical, but it makes a serious dent in the algorithm’s security.

Now, POODLE is different from those, because the specific attack scenario suggested is quite practical. So, let’s talk a bit about POODLE and how it works…

What is this vulnerability about?

By default, many if not all SSL-based applications will use TLS (Transport Layer Security), which is a class or more modern protocols intended to replace the older SSL versions 1.x, 2.x and 3.0.

Many applications will try to use TLS, but will automatically fall back to older SSL versions if they detect a server that does not support TLS. Not all client applications implement this fallback, but many do – particularly web browsers, but also some others.

POODLE combines a weakness in SSL 3.0 with a new attack on the protocol handshake. Attackers who are able to interfere with the handshake can force clients to fall back to SSL 3.0.

Does this mean an attacker can decrypt all my traffic?

Theoretically, yes. But really, it’s a bit like the movie scene described above, of Tom Cruise breaking into the barn.

Practically, based on what we know of this vulnerability today, the attacker needs to induce the client to attempt a non-neglible amount of connections in order to guess a a few bytes of data. On average, the attacker needs your client to attempt 128 connections in order to guess a single byte of the clear text that was sent.

How does the attack work?

A somewhat practical attack has been suggested on a web browser. It involves an attacker who controls the network communication between the victim client and service, and is able to insert a piece of javascript code into the victim’s web browser. This script will send HTTPS requests to some site (like intranet.yourcompany.com), into which the browser will automatically embed the cookies it has cached for this site.

By varying the length of the URL of the request and the amount of data in the request body, the attacker can influence the relative position of the cookie data within the SSL message sent as well as the trailing amount of padding generated by SSL.

I am not going to rehash all the cryptographic details of the attack here; you can find detailed descriptions at https://www.openssl.org/~bodo/ssl-poodle.pdf or https://www.dfranke.us/posts/2014-10-14-how-poodle-happened.html, for example.

Suffice it to say that this attack scenario allows the attacker to decode the cookie data one byte at a time, by sending up to 256 HTTPS requests for each byte of clear text.

In summary, this attack is complicated but well within the capabilities of skilled and resourceful attackers.

What about HTTPS based applications other than web browsers?

Obviously, based on the description above, web browsers that can be tricked into downgrading to SSLv3 are vulnerable, and continuing to use them is a risk on par with cross-site scripting attacks etc.

Other applications that probably have the highest risk right now are those that transfer small amounts of secret data (authentication tokens such as passwords, cookies, etc) over HTTPS. This includes web browsers, but potentially also applications based on SOAP or XMLRPC. How high that risk is depends on the attacker’s ability to influence the actual HTTP requests being sent.

Applications that use HTTPS, but use mutual authentication based on public key cryptography instead of passwords and cookies, should be harder to exploit.

As a matter of caution, any applications relying on HTTPS should be reconfigured as quickly as possible to disable all SSL versions older than TLS 1.0.

Are all SSL based applications vulnerable?

As always, it is hard to quantify the risk in absolute terms, and it is hard to exclude any class of application as “definitely not vulnerable”. These kinds of statements sometimes have a tendency to turn into fairly painful boomerangs.

So, the following discussion carries a big disclaimer: this is based on my understanding of this vulnerability today. Further research may reveal additional weaknesses that could help attackers exploit other applications and protocols as well.
To be able to judge the risk of different applications a bit better, let’s look at the prerequisites of the POODLE attack. The attacker needs to be able to

  • trick the client into sending lots of messages
  • the attacker needs to know which SSL message contains the secret data
  • the attacker needs to be able to align the secret’s position inside the message at will, e.g. by byte stuffing the message at its start
  • the attacker needs to control the size of the message, e.g. by byte stuffing the message at its end.

When sending data across an SSL encrypted connection, your data will be broken up into SSL messages, each of which is encrypted and contains a Message Integrity Code to detect tampering.

In HTTPS requests, the entire request usually ends up within a single message – which allows the POODLE attack to succeed.

However, things become more difficult with other protocols. For instance, protocols that involve a sequence of command/response exchanges will always transmit each command and each response as separate SSL Messages. The reason for that is, of course, that the server needs to ensure that a command is legit before executing it.

Now, most IMAP servers are set up for some sort of password based authentication, either using LOGIN or AUTHENTICATE PLAIN. When the client does the authentication, it will always send a command like this:

A0001 LOGIN okir "SuperSecret"

This ends up being wrapped in an SSL message all by itself – with no obvious way for an attacker to insert any stuffing before or after the password.

Of course, there may still be other interesting attacks on protocols like IMAP or SMTP that may allow an attacker to obtain the list of messages in your mailbox and other bits of interesting information.

However, based on the above, it seems that there’s no way how POODLE can be used today to retrieve IMAP or SMTP passwords, or similar network protocols based on a command/response pattern.

As a vendor, can’t you just patch all applications to disable SSLv3?

We consider doing this for some applications and libraries, but this is a drastic measure that would negatively impact those customers and users who require SSLv3 due to client or server applications that have not been enabled for TLS.

For now, we refrain from making such changes in any applications, but may do so at a future point in time.

Can’t you just patch openssl?

Unfortunately, there is no programmatic fix available. This is a flaw in the protocol, and the only remedy known at this time is to configure the affected services to disable SSLv3 where possible.

There is a recent addition to the SSL protocol that can help thwart any downgrade attacks. It is called TLS_FALLBACK_SCSV, and recent updates to openssl implement this feature.

However, just providing this feature in openssl and other libraries like gnutls doesn’t achieve anything. What it does, however, is to help applications detect an illegal downgrade after it has happened, and terminate the connection immedaitely. For this, both client and server need to support this feature, and the client needs to have code that checks for this condition.

In essence, what this does is that after a successful handshake, the server informs the client about its cipher suites. A client can then compare to what TLS versions it has tried – and if it sees that one of the TLS versions that failed should have worked, then it knows something is fishy.

Some browsers have implemented this already – among them Google chrome Most haven’t, however. But I expect those that haven’t will follow quite quickly.

Does it mean I can lean back once I’ve patched my web server and browser applications?

I would advise against that. SSLv3 is really old. TLS 1.0 has been published in 1999, so it’s about time to retire at least SSLv3. Ultimately, the decision on how fast to retire it is yours. I wouldn’t wait too much longer.

(Visited 1 times, 1 visits today)

Leave a Reply

Your email address will not be published.

No comments yet