[ISN] Vulnerabilities in the Media -- who to trust?

From: InfoSec News (isnat_private)
Date: Tue Apr 01 2003 - 01:47:24 PST

  • Next message: InfoSec News: "[ISN] InfoSec News Book Giveaway - Honeypots: Tracking Hackers"

    +------------------------------------------------------------------+
    |  Linux Security: Tips, Tricks, and Hackery                       |
    |  Published by Onsight, Inc.                                      |
    |                                                                  |
    |  01-April-2003                                                   |
    |  http://www.hackinglinuxexposed.com/articles/20030401.html       |
    +------------------------------------------------------------------+
    
    This issue sponsored by Building Linux VPNs
    
    Building Linux Virtual Private Networks offers concise, step-by-step
    instructions for building VPNs based on both standard protocols
    (IPSec, SSL, SSH, PPTP) and popular Linux VPN solutions (VTun, cIPe,
    tinc). Through numerous examples and proven practices, you will gain
    important insights into choosing a VPN solution, installing and
    configuring it, setting up routing, configuring firewalls, measuring
    performance, and much more.
    
    For more information, visit http://www.buildinglinuxvpns.net/
    
    --------------------------------------------------------------------
    
    Vulnerabilities in the Media -- who to trust?
    By Brian 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.
    
    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. by their
    
    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.
       
    The voices of authority 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 asside, 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.
    
                                -------------                            
    Brian 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. Brian can be reached at
    brianat_private
    
    --------------------------------------------------------------------
    This newsletter is distributed by Onsight, Inc.
    
    The list is managed with MailMan (http://www.list.org). You can
    subscribe, unsubscribe, or change your password by visiting
    http://lists.onsight.com/ or by sending email to
    linux_security-requestat_private
    
    Archives of this and previous newsletters are available at
    http://www.hackinglinuxexposed.com/articles/
    
    --------------------------------------------------------------------
    
    Copyright 2003, Brian Hatch.
    
    
    
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.
    



    This archive was generated by hypermail 2b30 : Tue Apr 01 2003 - 08:54:08 PST