[Politech] Jake Appelbaum summarizes flaws in "CIPE" Linux security tool

From: Declan McCullagh (declan@private)
Date: Mon Sep 29 2003 - 22:05:27 PDT

  • Next message: Declan McCullagh: "[Politech] John Gilmore on showing ID when entering buildings [priv]"

    [This is a little obscure but perhaps worth reading through if you're 
    interested in how the open source community responds to news of security 
    vulnerabilities. The crucial background is here: 
    http://www.mit.edu:8008/bloom-picayune/crypto/14238 --Declan]
    
    ---
    
    Subject: My response to both the analysis of CIPE by Gutmann, Slashdot and
    	the response by the CIPE list
    From: Jake Appelbaum <jacob@private>
    To: declan@private
    Date: 25 Sep 2003 03:35:23 +0200
    
    Please allow me to introduce myself.
    
    I am neither a CIPE developer nor a cryptanalysis expert.
    
    I am however a security consultant who deals primarily in Free/Open
    Source Software. I have used CIPE in the past as well as other
    Free/Open/Non-Free products for use in a VPN solutions.
    
    I wanted to contribute an outsiders perspective.
    
    I first read Peter Gutmanns analysis [1] as linked from Slashdot [2] and
    later I found the archive for cipe-l [3].
    
    After reading Gutmann's short but to the point email a few points that
    he made seemed obvious. Some of the flaws were not so obvious. CIPE
    seemed to have some very simple flaws and some of the fixes were easy to
    implement.
    
    I found a some of it delivered in such a manner that would upset people
    who were highly vested in the projects he was criticizing. Perhaps it was
    the comment that I also found to be so amusing, something to do with
    sound waves. Amusing as it may be, it's still quite harsh.
    
    I then read through the posts on Slashdot that declared CIPE to be
    dead. I found these to be really immature and silly considering the
    nature of F/OSS.
    
    The need for some change is now, not the time for it's funeral.
    Thanks to the F/OSS method of development this is all very possible.
    
    The only series of comments on Slashdot worth reading (IMHO) were by Dan
    Kaminsky [4].
    
    I also went ahead and read the CIPE FAQ [5].
    
    A few statements seemed a little hard to believe after Gutmanns pointing
    out of using CRC-32 (as opposed to say SHA1).
    
    These really stuck out:
    
    "To date one case of a potentially exploitable bug has been found,
    luckily in a version which never was widely used. Another bug has been
    found which could lead to denial of service attacks. Both have been
    fixed."
    
    [...]
    
    "As for CIPE vs. IPSEC, they should be equivalent security-wise, with
    CIPE giving a bit better performance because of the lightweight
    protocol."
    
    Peter Gutmann had stated that some of his findings were actually found
    years prior, thus the first statement seems to be false.
    
    The second statement is just a bald faced lie, unless it was written by
    someone from a decade ago. The CIPE protocol description [6] says
    outright that CIPE uses CRC-32 for *integrity protection*.
    
    An important statement to take into account from the protocol
    description:
    
    "The primary goal of this software is to provide a facility for secure
    (against eavesdropping, including traffic analysis, and faked message
    injection) subnetwork interconnection across an insecure packet
    network such as the Internet."
    
    With that said and with the analysis by Gutmann, let's get onto the list.
    
    The list I assumed would be delighted to have a professional
    cryptographer take a look at their tool of choice. I think the going
    rate for an actual security audit by a trained professional is somewhere
    around $60,000 (USD). This is a security related tool and as such needs
    this type of attention. Tools that would not like this type of audit
    might as well be snake oil.
    
    However deep this audit went, it does point out a number of problems.
    Actual problems that need to be addressed for the users of CIPE and
    fixes that need to be coded by the developers.
    Some of them are very valid at the time of writing, some of them are not
    practical without using a stateless encryption system (as Dan Kaminsky
    explains in his Slashdot posts).
    
    There are (as of this writing time) three major threads on the subject
    of Gutmanns email.
    
    The major first thread has responses ranging from defending CIPE and
    understanding the authors stated claims [7]. The author of this post
    creates a nice numbered list to respond to. He misunderstands the
    statement about CIPE being "Linux's answer to MS-PPTP." He also goes on
    to start questioning Gutmann about things including message insertion.
    
    It also extends to a personal attack about Gutmanns ego. The message is
    then summed up as: "The bottom line for me is that CIPE is not less
    secure compared to many commercial products. The CIPE protocol is not
    that easy to break as suggested by Gutmann, but the protocol surely has
    room for improvements. If you enable data compression (CipeX) it is even
    more complicated to break the protocol: you first need to decrypt to
    de-compress, and it is extremely difficult to guess the contents of a
    compressed ip-packet, which guessed content is needed to break the
    encryption."
    
    These statements are preposterous. With an arbitrary comparison to
    "many commercial products," whatever metric that is. That it's "hard"
    for "someone" to break, but that it's still very much possible. Being
    alright with this is quite amazing. This is a security project.
    Difficulty is very relative and for Johnny hacker, it might be hard.
    However an example of making it hard to decrypt by using compression is
    a great example of misunderstanding. A UDP packet with a static key that
    has a compressed payload can be replayed over and over and over again. No
    key required. The compression isn't going to be a secret either right?
    So it's still going to be possible to do plain text attacks of the same
    magnitude regardless of the way the data is before cyphers are applied.
    
    The follow ups to this are much like a rally behind a weak player [8]
    with a few exceptions [9].
    
    Others want to wait for Olaf (the primary author of CIPE) to speak on
    this issue before making any major conclusions [10]. Some people are
    thanking for tool that has some major flaws as pointed out by a well
    respected cryptographer [11] and some think it could be pro money making
    FUD [12].
    
    The fact that Olaf hasn't replied is a huge problem for my assurances
    that this project is on track to fix these problems, I know that I am
    not alone [13]. What is more shocking to me is the lack of understanding
    about a protocol/security method being broken. It seems that many people
    doing small tests of their own [14] find it to be acceptable because it
    will fit their clients needs. Their own greed and the ease of setup
    being the bottom line.
    
    Other people seem just fine with CIPE being "less than a bank vault" and
    I find this just amazing [15]. This is a project that claims the highest
    in industry stands. These are people giving away secure systems. That
    type of response is insane. One poster even seemed happy with these
    statements against CIPE and bragged of it's use in "every sector you can
    imagine" [16].
    
    Perhaps the most together response has been by someone running a small
    company who had customers upset by Gutmanns statements [17]. This person
    acknowledges many of the concerns but down plays some of the more
    important ones. Statements that Gutmann is playing up the CRC-32
    problems (in relation to SSHv1) making it sensationalist are invalid. This
    is very much a valid concern. However he does a great run down of the
    concerns and is very much an important statement.
    
    Gutmann himself writes "A Coda to "Linux's answer to MS-PPTP" [18]."
    This is a well thought out response to the letters he has no doubt been 
    flooded by.
    
    This product has been adopted by people around the world who may or may
    not depend on it as much as the next person. This however says to me
    that it's very important to have a response by Olaf, fixes implemented
    and even though Gutmann was rude, he should be thanked. If these fixes
    are implemented, people who depend on CIPE will have something that is
    not broken. It is clearly broken and it needs to be addressed, users
    need to be alerted. A proof of concept should not be needed in this
    case. I imagine however that it won't be very long before someone writes
    a proof of concept ettercap plug-in to mess with CIPE if this isn't
    fixed.
    
    People depend on software like CIPE and it can cost them dearly if
    situations like this aren't fixed. It's not always about business
    either, sometimes lives are at stake. Those people might not stand up
    and demand something be done, but someone should.
    
    Let us make sure that this gets fix. Let us also make sure that this
    situation is handled well and discussed openly. If it's ignored, we can
    know that the relation of CIPE to snake oil is inversely proportional to
    the amount of work spent fixing it by it's project leads.
    
    [1] http://www.mit.edu:8008/bloom-picayune/crypto/14238
    [3] http://slashdot.org/article.pl?sid=03/09/22/2127236
    [3] http://sites.inka.de/bigred/archive/cipe-l/2003-09/threads.html
    [4]
    http://slashdot.org/comments.pl?sid=79554&cid=7029635&pid=7029635&startat=&threshold=1&mode=nested&commentsort=0&op=Change
    [5] http://sites.inka.de/sites/bigred/devel/cipe-faq.html
    [6] http://sites.inka.de/sites/bigred/devel/CIPE-Protocol.txt
    [7] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00200.html
    [8] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00211.html
    [9] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00193.html
    [10] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00194.html
    [11] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00197.html
    [12] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00227.html
    [13] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00228.html
    [14] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00192.html
    [15] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00203.html
    [16] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00209.html
    [17] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00225.html
    [18] http://www.mit.edu:8008/bloom-picayune/crypto/14258
    
    -- 
    Jake Appelbaum <jacob@private>
    
    _______________________________________________
    Politech mailing list
    Archived at http://www.politechbot.com/
    Moderated by Declan McCullagh (http://www.mccullagh.org/)
    



    This archive was generated by hypermail 2b30 : Mon Sep 29 2003 - 22:43:34 PDT