Vulnerabilities in the Media -- who to trust?
By Bri Hatch.
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.
- 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.
- 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 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.
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:
The voices of authority
- "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.
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
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.
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
- 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.
Anyone who writes a column on April Fool's day is certainly
trustworthy - wouldn't you agree?
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.
- The actual writeup about the attack
- OpenSSL's advisory about the problem, announcing the fixed versions.
- The BBC's version of the story. They've edited it heavily to make it more accurate than the first version.
- The Slashdot discussion about the vulnerability
- I can't find the CNN page any more, but it was an absolute gold mine for erroneous information.
- ZDNet's "experts discredit e-mail security cracks" followup article.
 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.
 They claimed to be able to decrypt an IMAP password by interfering with the connection 160 times.
 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
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
Bri can be reached at firstname.lastname@example.org.
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_Securityemail@example.com.