root labs rdist

January 25, 2008

TLS/SSL MAC security flaw

Filed under: Crypto,Network,Security — Nate Lawson @ 12:47 pm

Following my recent posts on TLS/SSL security, I gave a talk (slides are here) on a security flaw in the record layer that was fixed in TLS 1.1. The last page of my slides gives some interesting links if you’re interested in understanding SSL security better.

This flaw (found by Bodo Moeller) is in the use of padding as part of the integrity protection of the actual data being exchanged. Padding is needed because block ciphers encrypt data in chunks and something has to go in the remainder of the last block. This attack is particularly interesting because it allows an attacker to iteratively decrypt part of the message using side-channel leakage.

Side channel attacks are still often neglected, despite proof that they can be performed over the Internet. System designers always seem to have the same initial response when learning about timing attacks: make the computation time constant by adding a calibrated delay. When problems in this strategy are pointed out, their next move is to add a random delay after the computation (not blinding).

This usually repeats with each approach getting shot down until they eventually admit this is a hard problem and that appropriate measures need to be integrated with the actual process (not bolted on) and carefully evaluated for unforeseen problems. For example, one fix for this attack is to always compute the MAC even if the padding is incorrect. However, the logic path of noting that the padding is incorrect but continuing anyway still requires a conditional branch, which creates a small but observable timing difference that can be used in a successful attack.

Preventing side channel attacks is a difficult problem. If confronted with them, take the time to get your countermeasures carefully evaluated.

January 14, 2008

Ptacek vs. Lawson: 2007 predictions revisited

Filed under: Misc,Security — Nate Lawson @ 8:57 pm

You’ve just finished opening your seventh corporate calendar gift. You’re ten pounds heavier. What better way to celebrate 2008 than revisiting our predictions from last year ?

Nate: Predicted! 99% of spam comes via image attachments

[N] Wrong. I do get lots of image spam and PDF attachment spam was new in 2007, but the lack of “clickability” limits the usefulness of this type. This year, I resolve not to make predictions about spam.
[T] I got more spam from Ron Paul supporters this year than I did from image attachments. I may be 6 months behind the times in calling this an ’07 result, but the bigger news in antispam seems to be the failure of Bayesian antispam filters. Remember when Bruce Schneier wrote that article calling antispam software one of the industry’s success stories? I’d regret that column today if I had written it. And, not that I think this blinding flash of inspiration makes me Kreskin or anything, but the other trend? Email is no longer the frontier of spam; online communities like Facebook are.
[N] Akismet is still a success story.

Thomas: Predicted! A New Mainstream Bug-Class

[N] Right, although a lot of the C++ stuff was already started last year.
[T] I’m giving myself a clean win here: 2007 was the year that C++ fell, in the mainstream, thanks largely to Mark Dowd and John McDonald. The bug class everyone seems to remember here is the delete/delete[] thing: because of C++’s asinine inability to distinguish an array from other complex objects (including vectors), you can lose a program to using the wrong delete operator. But the “rest” of the problems here are far worse. For instance, pretty much nobody has ever written a C++ program without an STL iterator bug. And Alexandrescu-style “modern” C++, which replaces pointers with smart pointer templates, creates memory lifecycle vulnerabilities every time data passes an API boundary. A huge chunk of our infrastructure was written in C++ in the mid-late ’90s, and until recently there was a mass delusion that C++ was safer than C. I don’t want to get into predictions for ’08, but, I just did.

Nate: Predicted! The “Month of X Bugs” meme fades out, finally

[N] Yay, right.
[T] Thank god. Least said, soonest mended.

Thomas: Predicted! A Year Of Cisco Vulnerabilities

[N] Wrong, no one is paying attention to networks right now. As I said, PC/Windows and shiny devices (iPhone) were what attracted researchers this year.
[T] I can’t claim to have nailed this prediction. But I’m not so sure of your policework there, Nate. Nobody is paying attention to IOS vulnerabilities? That’s not what’s holding back the flood: the finger in the dike right now is the fact that few people can find bugs in IOS. How many skilled vulnerability researchers are there in the whole industry? Oh wait: we figured that out two years ago — a good SWAG guess is 1,000. Of 1,000, how many can do low-level C vulnerabilities? A generous half? Of those 500, how many read assembly fluently? Half again? Of those 250, how many have the time and inclination to reverse undocumented embedded operating systems? If there are 100 people in the world who are currently IOS-qualified researchers, I’m shocked.
[N] You mention that skilled researchers are lacking, but I still maintain that is because they’re all focused elsewhere right now. FX, initiator of Cisco buffer overflows, was talking about bar codes this year.

Nate: Predicted! Apple follows OpenBSD, Linux, and Windows, by adding OS hardening features

[N] Right, Leopard did although their ASLR needs some improvement. Also, they threw in a weird userland firewall implementation that no one expected.
[T] Swing and a miss! I grudgingly concede this prediction to you; they did add, uh, “stuff”. But it’s a huge mixed bag, and if you just look at the places where they followed OpenBSD and Windows, they failed decisively. Whatever the Wikipedia editors might want to say, Leopard ASLR is broken and irrelevant; a shellcode tweak speedbump at best. On the other hand, Apple is blazing a new trail in MAC and program sandboxing; the TrustedBSD extensions they’ve provided to lock programs into OS capabilities appear strong, and could finally give OS X a real security advantage over Win32, if Apple handles them well.
[N] You conveniently overlook the fact that I didn’t claim OSX would be more secure than Vista after the changes, only that they would add similar features. The MAC layer is already present in Darwin, just not enabled by default. It will also be interesting to see if they can do it [Allow?] in a less annoying [Allow?] way than Windows [Allow?].
[T] It’s interesting that the most effective Windows security solutions are the behind-the-scenes runtime improvements, and the most effective Apple security solutions are design-level changes. Oh, wait, no, that isn’t interesting.

Thomas: Predicted! Bruce Schneier Will Not Score A New York Times Op-Ed

[N] I’m wrong also. Schneier did not make the move to tamper resistance, but attackers did enter crypto in a big way. Xbox hackers used timing attacks against the 360, and the Mifare stream cipher was reversed with hardware techniques.
[T] This prediction was wrong just days after I made it; Schneier got an op-ed on the airport security CLEAR program on January 21. Schneier gets steadily less relevant to hard skills security every year, but I’ll make a 2009 prediction: he’s going to be angling for a role in politics.

Nate: Predicted! Zero-day exploits in client apps like Office outnumber researcher advisories

[N] Wrong. It looks like Microsoft themselves are finding the most bugs, as should any company that cares about security.
[T] Zero day clientsides increased in ’07, but organically, not exponentially. I call this a miss.

Thomas: Predicted! Drastically Fewer Windows XP/Vista Vulnerabilities

[N] Easy gimme for you. But I was also right in that 3rd-party signing would prove ineffective (example: Joanna’s ioctl flaws found in common signed drivers).
[T] I give myself no credit for predicting this. You only have to make one assumption to figure this out: money buys improved security. Nobody in the industry spends as much as Microsoft on software security. Nobody spends more directly, on third-party software security testing. Nobody spends more internally, on full-time security practitioners, researchers, engineers and trainers. And nobody spends more indirectly, bearing the cost of improved security in every stage of their release cycle. My company probably does less Microsoft work than any other top-tier independent consultancy, but you can call me out for a conflict of interest here. I repeat and amplify this prediction for 2008.

Nate: Predicted! Content producers strike back: broadcast flag legislation passes and shuts down

[N] Wrong, but Germany did outlaw “hacker tools”.
[T] Here’s what I think: either Macrovision is going to step up and make Blu-Ray’s BD+ scheme a success, and we’re going to have hundreds more crappy DRM schemes, or the critical mass of studios backing off on DRM is going to result in the end of software protection. In a way, it’s too bad: software protection is a fun problem, and one of the few (maybe spam is the only other) where each side of the fight is so evenly matched. I’m watching BD+ in 2008, and I’m not telling you who I’m rooting for.
[N] The big news for 2007 is that the battle for music DRM is over. MP3 (FLAC actually) wins. I’ve refused to buy music online until I can get it in a non-lossy format. It’s too early to predict an outcome for high-def movies, but it seems already obvious that revocation alone is a bad strategy. I’m shying away from making a prediction here due to conflict of interest (I’m a co-designer of BD+) but I will say that in 2008 studios will see the value in a system that requires continual effort by hackers to break each disc versus one that doesn’t.
[T] My siblings don’t share your hatred of DRM; I don’t think Steve has ever asked himself, “what would Nate do?” (people at Matasano do all the time, though).

Thomas: Predicted! TSA Starts Checking Software On Laptops

[N] Wrong, but they did start checking lithium batteries as I hinted.
[T] I retain this prediction for ’08. If you had asked me last year, “which is more likely: a TSA malware screening of laptops due to a scare about wifi and software radios interfering with avionics, or a blanket ban on a phase of matter”, I would not have predicted the ban on the phase of matter.

[N] In summary, both of us got two right. None of our far-reaching predictions came true.
[T] I was right about the bug class. We’ll be dealing with that one for the next 5 years.
[N] We also did something different in terms of giving counter-predictions in response.
[T] I got four counter-predictions right (anti-spam — though I did not anticipate the Paulbots, Month-of-X-Bugs, Apple, and Office zero-days).
[N] I got two right (no IOS hacks, crypto attacks mainstream).
[T] I’m apparently the better predictor, but only when I’m disagreeing with someone else.
[N] I disagree?

Next Baysec: January 17 at Pete’s Tavern

Filed under: Security — Nate Lawson @ 5:04 pm

The next Baysec meeting is at a new location, Pete’s Tavern. Come out and meet fellow security people from all over the Bay Area. As always, this is not a sponsored meeting, there is no agenda or speakers, and no RSVP is needed.

See you on Thursday, January 17th, 7-11 pm.

Pete’s Tavern
128 King St. (at 2nd)
San Francisco

January 11, 2008

Avoiding Comcast BitTorrent blocking

Filed under: Network,Security — Nate Lawson @ 12:02 am

Tonight I attended and spoke at the iSec Forum. My topic was recent flaws in TLS/SSL that were fixed in version 1.1. I’ll continue posting details about them here.

There was a good talk by Seth Schoen of the EFF on detecting RST-spoofing attacks by ISPs. He built a tool called pcapdiff that lets you compare client and server-side packet captures to see if someone is dropping your packets or spoofing new ones. This is what they used to catch Comcast blocking BitTorrent connections, among other things.

The approach Comcast apparently uses is to send TCP RST packets to both endpoints whenever the Comcast user’s BitTorrent client offers to seed a complete file. It doesn’t interfere with downloads, presumably because that would lose them a lot of customers. However, by preventing uploads once the download is completed, it prevents users from increasing their share ratio or offering new files for sharing.

I mentioned a simple countermeasure BitTorrent developers might use. Instead of announcing a complete seed, every client would announce a complete file except for a single chunk chosen at random. The random chunk index would be changed at a regular interval. That way, clients requesting a chunk would get it nearly all the time but the seed would never get blocked because it wasn’t complete. This behavior (hack?) could be disabled by default.

This is yet another example of the vantage point problem. Few system designers seem to understand its far-reaching implications. For background, see Ptacek and Newsham or Blaze. The latter summarizes it this way:

“There is unfortunately little room to make conventional loop extender interception systems more robust against these countermeasures within their design constraints; the vulnerabilities arise from inherent properties of their architecture and design.”

[Epilogue:  Azureus developers indicated to me that they have already implemented this option as "lazy bitfield".  Additionally, they have a weak encryption option for peer chunk transfers.  However, neither of these have an effect on Comcast, who appear to be using Sandvine to implement this blocking.  Instead, they seem to be monitoring connections to the tracker and correlating them with bandwidth consumed by uploading.]

January 7, 2008

SSL PKCS padding attack

Filed under: Crypto,Network,Security — Nate Lawson @ 3:28 pm

The first notable attack on SSL 3.0 was Bleichenbacher’s PKCS#1 padding attack (1998). This gave the astonishing result that any possible side channel that gave information about the result of the RSA decryption could be used to iteratively decrypt bits of a previous session key exchange. This was recently applied to an attack on the version information added to the PKCS#1 padding in SSL 3.0.

The fix to these attacks is to substitute random data for the PremasterSecret and continue the handshake if the RSA decryption result fails any validity check. This will cause the server and client to calculate different MasterSecret values, which will be detected in the encrypted Finished message and result in an error. (If you need a refresher on the SSL/TLS protocol, see this presentation.)

Note that this approach still leaves a very slight timing channel since the failure path calls the PRNG. For example, the initial padding bytes in the result would be checked and a flag set if they are invalid. But that check involves a compare and conditional branch so technically there’s still a small leak. It’s hard to eliminate all side channels, so countermeasures to them need to be carefully evaluated.

The attack is quite clever and illustrates RSA’s malleability that I wrote about in this earlier series of articles (with Thomas Ptacek). It involves successive approximation, zeroing in on the value of the plaintext message M by sending variants of the ciphertext (C) to the server. The server decrypts each message and reports “padding incorrect” or continues processing. Remember, this oracle doesn’t have to explicitly report an error message, although that’s the most obvious way to distinguish the decryption result. It could just be a timing difference.

If the server does not report “padding incorrect”, then the attacker knows that the decryption result had the proper PKCS#1 padding (e.g., starts with the bytes ’00 02′ among other things) even though the remaining bytes are incorrect. If these bytes were uncorrelated to the other bytes in the message, this wouldn’t be useful to an attacker. For example, it’s easy to create a ciphertext that AES decrypts to a value with ’00 02′ for the first two bytes but this doesn’t tell you anything about the remaining bytes. However, RSA is based on an algebraic primitive (modular exponentiation) and thus does reveal a small amount of information about the remaining bytes, which are the message the attacker is trying to guess. In fact, an early finding about RSA is that an attacker who can predict the least-significant bit of the plaintext can decrypt the entire message.

The first step of the attack is to create a number of variants of the ciphertext, which is c = me mod n. These are all of the form c’ = cse mod n, where s is a random number. Once this is decrypted by raising it to d (the private exponent), the s value can be masked off by multiplying it by s-1. This property is used in blinding to prevent timing attacks.

The second step is to send these values to the server. It decrypts each one and reports a “padding incorrect” error or success (but with a garbage result). For the s values that result in correct padding (’00 02′), the attacker knows the most-significant bit of the result is 0. In the paper, Bleichenbacher refers to this case as 2B <= ms mod n < 3B, which gives an interval of possible values for the message m. As more and smaller s values are found that are PKCS conforming, the number of possible intervals is reduced to one. That is, the union of all conforming msi values eliminates false intervals until only one is left, the one that contains the desired plaintext message.

The third step is to increase the size of the si values until they confine the message m to a single value. At that point, the original plaintext message has been found (after stripping off the given si value).

While this is a brilliant attack with far-reaching implications, it also illustrates the fragility of algebraic cryptography (i.e., public key) when subjected to seemingly insignificant implementation decisions. What engineer would think reporting an error condition was a bad thing?

The Rubric Theme Blog at


Get every new post delivered to your Inbox.

Join 81 other followers