Summary: There are a variety of people and entities that publish information about security problems. Who should you trust?

It seems that there are more sources of information about Security problems every day. The hardest part about trying to keep up with it all is to figure out who to trust. Let's take a recent example.

Back in mid February, 2003, scientists at a Swiss university were able to exploit a weakness in an SSL implementation to allow them to discover the password being repeatedly sent in many SSL-wrapped IMAP sessions.

The Facts

• This only affected the OpenSSL implementation of SSL
• The vulnerability relied on a timing attack - the SSL server would not perform all it's number crunching if it found that the data had been tampered with. By tampering with the inbound data in a careful manner, they were able to determine how 'valid' it was by measuring the time it took for the server to complain.[1]
• Any malicious hacker, in order to perform this kind of attack, would need to be able to rewrite packets as they were transmitted, man-in-the-middle fashion. One could not sit passively and listen to perform this attack.
• The data to be decoded needs to be in a predictable location, and sent frequently enough[2] times that they can discover the plaintext.
• Each time they try to attack an SSL session, the client and server will notice the error. You'd not successfully get your email while you were being attacked, and you'd probably stop trying after a while, or ask the administrator to check things out.

The Hype

Shortly after the announcement, every website with a readership of three or more seemed to be saying that SSL had been broken -- the end of the Internet was near -- all your passwords are belong to us. In the huge noise some amazingly erroneous statements were made:

• "Hackers can read all your data now"

  No, they can only try to manipulate your transmissions to decode a particular section of it. This sensitive info needs to be in a predictable place each time.

• "The attack only affects webmail"

  No idea where they came up with this one - the attack was tried out on IMAP over SSL. Webmail is usually straight HTTPS, and the password may only be sent once, and cookies used thereafter. Additionally, the sensitive data could move around for subsequent connections making it impossible to be sure what to attempt to decrypt.

• "SSL has been broken!"

  No, just one particular SSL implementation - OpenSSL - had the vulnerability, and it was fixed shortly thereafter.

• "The flaw is in SSL, not a particular implementation!"

  No, didn't you just listen to me?

• "Old SSL sessions you've used can now be decrypted! Change your passwords!"

  No, the attacker needed to attack you at the time you were using SSL. But you should change your password anyway -- "Linus" was too easy to guess.

• "You'd never know you'd been hacked!"

  No, any manipulation by the attacker destroys the SSL connection, so you'd get obvious errors and know something was amiss.

• "It only affects (Outlook/Hotmail/Yahoo)"

  The tests were done against Outlook, true, but any client software that sends a password frequently in a predictable location would have been vulnerable. Hotmail and Yahoo don't.

• "It only affects IMAP"

  No, it could affect anything where a password or something else 'secret' is in a predictable place, for example if you're using HTTP Basic authentication. The location will vary a lot more - it's not nearly as defined as an IMAP connection which always begins with login/password right up front.

All sorts of places reported and sensationalized the problem. It was a mad rush to have the first story.

Then came the experts.

The security geeks and cryptographers came out and tried to shed some light on the actual cause and likely attack scenarios. They explained what was actually broken, how it was being fixed, and how the "end of the Internet" was going to need to wait for another day. Some sites updated their articles to reflect this 'new' data. Others left the articles untouched, while others removed them but posted no retractions.

The analysis

With all the hubbub, rumours, and apocalyptic warnings, who are you to believe when news about a new vulnerability comes to light? Here's a very quick list:

• The folks to avoid:
  • Open Source Vendors
    These guys clearly have something to hide, and should not be trusted. The guys who develop OpenSSL keep everything about their product under lock and key - in order to see the actual source code, you need to use esoteric commands like gunzip or tar. Some Open Source developers even use the GPL license, which is equivalent to a virus according to a reputable and impartial software development firm based in Redmond, WA. I don't think you should trust Open Source vendors - far to shifty, those folks are. You can never really know what they're up to.

  • Scientists
    These guys take the time to provide a well written description of the problem, how they exploited it, and what needs to be fixed. They are obviously not worth listening to. They use drab, boring, unintelligible "science speak" not because it's the most effective way of communicating without colouring the data with emotion, but because they did not have enough training in bad computer lingo. Had they spent their time in college learning to write exclusively using words and phrases like "cyberwarrior", "hack attack" and "Internet superhighway", do you think they'd use the language of mathematics and science? I think not. Somehow that drab language is supposed to be sensationalistic and generate lots of hype by average joes. I don't quite know how, but it's some sort of plot.

  • Independent Experts
    It is well known that independent security experts are merely individuals that didn't have enough luck to land a high-paying job at a big anti-virus or managed security company, and will lie, cheat, and do anything they can to be noticed in hopes that they can get one. Don't let that whole "independent" part confuse you - they answer to somebody, by not being an obvious lackey of a big security firm, you don't know who it is! Experts? How can they be? Only megacorps can have experts, it's a law or something. If you take out "independent" and "expert" from "independent experts" what are you left with anyway? Just the letter "s", and what good is that?

• The folks to trust:
  • Online Media
    These guys know that you can surf to any other site just as easily as theirs. They know that you don't need to wait a week to get a paper publication, you want your information now. To assure technical accuracy of all their articles, they keep a staff of at least seventy trained professionals from each area that they may cover in their stories. Yep, those "SSL is broken" articles went through some really strict scrutiny by trained staff cryptologists before being published far and wide moments after the original scientific publication was announced. They also have a huge Artificial Intelligence program that helps check sources in the off hours when the editors are sleeping.

  • Slashdot Users
    One of the requirements before you sign up for a Slashdot account is that you show proof of expertise in certain areas, and you are only allowed to post in those areas you are qualified for. You must also have continuing educational credits to maintain your right to post.

  • Al Gore
    The only slashdot user who doesn't need to take the continuing educational credits is Al Gore. He's been grandfathered on slashdot, since he created the Internet. He has exclusive right to the slashdot handle "Anonymous Coward", and he posts very frequently.

  • George W. Bush
    Come on, if Al Gore is on this list, and more than 50% of US voters think Bush is smarter than Al, clearly GWB should be trustworthy. And what's this "electoral college" thing I kept hearing about in 2000?

  • Steve Gibson
    Sure, he didn't pipe up about this vulnerability at all, but he's the single voice that told us how awful raw sockets in Windows XP are, and how the Internet would melt shortly after it was released. And he independently created a new form of SYN cookies to save us all from the frequent denial of service attacks he seems to constantly be attacked with. Sure, all that work by Bernstein and Schenk back in 1995 to create SYN cookies was wasted. "SYN cookies"? Come on, that's not marketable. But Gibson's "GENESIS" - now that has a ring to it. Who cares if it doesn't work.

  • Columnists/Authors
    Anyone who writes a column on April Fool's day is certainly trustworthy - wouldn't you agree?[3]

Ok, all April Fool's kidding aside, here are some links that discuss the OpenSSL bug that I talked about. It's been fixed for a while, and the Linux distros have had new OpenSSL library packages available since the end of February at the latest.

http://lasecwww.epfl.ch/memo_ssl.shtml

The actual writeup about the attack

http://www.openssl.org/news/secadv_20030219.txt

OpenSSL's advisory about the problem, announcing the fixed versions.

http://news.bbc.co.uk/1/hi/technology/2785145.stm

The BBC's version of the story. They've edited it heavily to make it more accurate than the first version.

http://slashdot.org/article.pl?sid=03/02/20/1956229

The Slashdot discussion about the vulnerability

http://www.cnn.com/....

I can't find the CNN page any more, but it was an absolute gold mine for erroneous information.

http://zdnet.com.com/2100-1105-985460.html

ZDNet's "experts discredit e-mail security cracks" followup article.

NOTES:

[1] The solution was to perform all the number crunching, even if the data was invalid, and then send back an error, thus eliminating the difference in timing results.

[2] They claimed to be able to decrypt an IMAP password by interfering with the connection 160 times.

[3] Ok, so I had a little fun with the "who's trustworthy" part of this article. But all the OpenSSL timing vulnerability stuff is accurate, including the degree of erroneous information portrayed in the media.

Bri Hatch has been developing Open Source Linux products since 1985, created the RedFishBlueFish block cipher used by default in SSL 4.0 servers, raises prize-winning alpacas in his back yard, and has an annual bake off that raises over 500 million dollars to be donated to needy Microsoft execs. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2003

This is the April 01, 2003 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.