Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Software Linux

Linux Crypto Packages Demolished 404

Posted by simoniker from the security-is-all-relative dept.
SiliconEntity writes "Cryptographer and security expert Peter Gutmann has demolished several Linux security software packages in a recent posting to the cryptography mailing list. He says, 'It's possible to create insecure 'security' products just as readily with open-source as with closed-source software. CIPE and vtun must be the OSS community's answer to Microsoft's PPTP implementation. What's even worse is that some of the flaws were pointed out nearly two years ago, but despite the hype about open-source products being quicker with security fixes, some of the protocols still haven't been fixed.'"
This discussion has been archived. No new comments can be posted.

Linux Crypto Packages Demolished More

Linux Crypto Packages Demolished

Comments Filter:

  • What a great Quote (Score:5, Funny)

    by G Money ( 12364 ) * on Monday September 22, 2003 @05:19PM (#7028720) Homepage
    I wish I could make this my signature (damn 120 char limit):

    "Whenever someone thinks that they can replace SSL/SSH with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve enlightenment."
    --Peter Gutmann

  • Use the trustworthy stuff (Score:5, Funny)

    by Anonymous Coward on Monday September 22, 2003 @05:20PM (#7028726)
    I only use the Cyrillic Projector code. No one ever will crack that.

  • Oh no! (Score:3, Funny)

    by Compact Dick ( 518888 ) on Monday September 22, 2003 @05:22PM (#7028746) Homepage
    Demolished? Where am I now gonna get my SSH and GPG from? :-(

  • POPTOP (Score:3, Interesting)

    by fmlug.org ( 695374 ) on Monday September 22, 2003 @05:24PM (#7028763) Homepage
    What about the poptop project at http://www.poptop.org/. There is also a really good client package at for pptp servers at http://pptpclient.sourceforge.net/ I use both and they seem to be much better then vtun and cipe.

  • CIPE (Score:5, Informative)

    by dnoyeb ( 547705 ) on Monday September 22, 2003 @05:24PM (#7028764) Homepage Journal
    When I investigated CIPE for the first time two days ago, I read somewhere on the site that it didn't work yet, or that it provided no security. How can you critize a package for being insecure when they tell you it is?

    Did I miss something?

  • thank you captin obvious (Score:5, Insightful)

    by Anonymous Coward on Monday September 22, 2003 @05:25PM (#7028767)
    he points to CIPE, a tool which hasent been updated since jun 02 and Vtun since aug. 2001. he says TINC was just as bad but was fixed when users complained. I think the obvious conclusion is that if people use the software and email the person who maintains it, it will get fixed. if the project goes stagnent because the author doesnt maintain it or people dont use it then of corse it will be vunerable after time as more flaws are discovered and not patched.

  • Give this man a PhD! (Score:5, Interesting)

    by volkerdi ( 9854 ) on Monday September 22, 2003 @05:25PM (#7028776)
    It's possible to create insecure 'security' products just as readily with open-source as with closed-source software.

    This sentence can be reduced to "It's possible to create insecure security products" without losing any important content.

    The question should be, is it possible to create a truly secure product when there's no opportunity for public code review? My answer would be "no". I shudder to think of how many critical holes would be found in most popular closed source network products if people like Michal Zalewski were allowed to review the source code.

    • Re:Give this man a PhD! (Score:2, Informative)

      by Anonymous Coward
      Dude: he already has a PhD in cryptography from university of auckland

    • Re:Give this man a PhD! (Score:5, Insightful)

      by Asprin ( 545477 ) <gsarnoldNO@SPAMyahoo.com> on Monday September 22, 2003 @06:24PM (#7029238) Homepage Journal

      #1 - He's right.
      #2 - So are you, or better yet consider this:

      If CIPE were closed source, would he have even been able to write this article? Unless I missed something, nobody ever claimed OS was flawless, just that the flaws were open to scrutiny.
      • If CIPE were closed source, would he have even been able to write this article?

        Yeah, 'cuz Windows being closed source prevents people from finding security vulnerabilities and writing articles on them...

  • GPG is also a disaster and other rants (Score:4, Insightful)

    by Anonymous Coward on Monday September 22, 2003 @05:26PM (#7028785)
    All these years after Phil Zimmerman released the original PGP code, we STILL don't have anything which satisfies the need for a securing email. It would have these properties:

    1. Be under a BSD-ish license, so it could be linked in to commercial and non-commercial products.

    2. Be a LIBRARY, not a stand-alone executable, so it can be linked into anything at all.

    Let's see, the Xiph people want their protocols to be used all over the place, so they make it a BSD-license LIBRARY that anyone can link to. Hmmm, seems to be working. The PNG backers want their format to be used all over the place, so they make it a BSD-license LIBRARY that anyone can link to. Hmm, seems to be working. The PGP/GPG people want their stuff to be used by people to send mail everywhere, so they make it either a non-Open Source license (PGP) or a GPL license (GPG) and also never ever make it a library for non-existant "security" reasons. Guess what! No one uses it!

    Oh, and while I'm ranting about the horribleness of Open Source security stuff, why is it that there is STILL no well-integrated filesystem crypto in any of the Open Source operating systems, including the security-oriented OpenBSD? No, loopback crypto kludges don't count at all.

    • Re:GPG is also a disaster and other rants (Score:2, Interesting)

      by Anonymous Coward
      You could make the argument that it should be GPL so that vendors can't silently change the implementation.

      I don't feel comfortable using crypto products without source code, I don't know about you.

      cipe has been on my shitlist for a long time for instance.

    • Debian to the rescue! (Re:GPG is also a disas...) (Score:5, Informative)

      by Anonymous Coward on Monday September 22, 2003 @05:52PM (#7029029)
      Package: libgpgme11
      Description: GPGME - GnuPG Made Easy
      GPGME is a wrapper library which provides a C API to access some of the GnuPG functions, such as encrypt, decrypt, sign, verify, ...

      Can I hump your skull now?
    • That has nothing to do with the license. It has to do with end users and the ease of using it. It needs to be integrated into the mail client and it needs to be easy to see and use.

      Most clients now spawn an exec and pipe data to PGP or GPG. Nothing in the GPL prohibits that.

    • why is it that there is STILL no well-integrated filesystem crypto in any of the Open Source operating systems, including the security-oriented OpenBSD? No, loopback crypto kludges don't count at all.

      My loopback crypto filesystems, set up on Mandrake Linux 9.0/9.1, don't seem all that kludgy to me. It was easy enough to set up and very easy to use. Except that I still have to mount my encrypted filesystems via the command line, what's up with that? If anyone knows of any GUI mount programs that are smar

    • The main article here isn't about security packages that are uglier than dirt, it's about "security" packages that are insecure. I'm not aware of significant security problems with GPG (as long as your trust models and operating environment are compatible with its requirements and capabilities), and you appear to be ranting about how ugly it is to use. Well, we all *knew* that...

    • Re:GPG is also a disaster and other rants (Score:5, Insightful)

      by stevenj ( 9583 ) <stevenj.alum@mit@edu> on Monday September 22, 2003 @06:03PM (#7029114) Homepage
      Be under a BSD-ish license, so it could be linked in to commercial and non-commercial products. Be a LIBRARY, not a stand-alone executable, so it can be linked into anything at all.
      Right, that's why no one has succeeded in making GPG-encryption plugins for Mozilla [mozdev.org], Eudora [sourceforge.net], Evolution [ximian.com], Outlook [sourceforge.net], and so on [gnupg.org].

      Those GNU folks are just evil; that's why they would never agree with something like the Vorbis BSD license [lwn.net].

      Or it could be that most people don't really understand the need for encryption, are hopelessly confused by key management, and won't use it until it is bundled with their computer and employed by default in their email program.

    • Re:GPG is also a disaster and other rants (Score:5, Insightful)

      by PureFiction ( 10256 ) on Monday September 22, 2003 @06:32PM (#7029282)
      Be a LIBRARY, not a stand-alone executable, so it can be linked into anything at all.

      If you read about GPG you would realize that the intentional lack of a library is a feature, not a bug. The GPG application relies on some cool extensions to protect memory areas used for the random pool (entropy source) the key generation algorithms, etc.

      The moment you pull that out into a simple library you open up a number of attacks. Perhaps the application using the library got 0wn3d by an LD_PRELOAD trick. Perhaps it is allocating memory poorly and it gets swapped to disk, where another rogue process picks it up. Perhaps another rogue library is scanning application memory space and writing keys to a socket over the network. etc, etc.

      There are a number of good reasons why there is no library (the current C libs are simply wrappers around exec to the gpg executable - they work fine, use them). Do you want convenience or real security?

      • Re:GPG is also a disaster and other rants (Score:4, Insightful)

        by SuperKendall ( 25149 ) * on Monday September 22, 2003 @06:48PM (#7029402)
        The moment you pull that out into a simple library you open up a number of attacks. Perhaps the application using the library got 0wn3d by an LD_PRELOAD trick....

        There are a number of good reasons why there is no library (the current C libs are simply wrappers around exec to the gpg executable - they work fine, use them.

        Excuse me for my ignorance of how GPG is called, but isn't just loading an executable from your path subject to the same sorts of attacks (really, easier onces) than the LD_LIBRARY_PATH modification? I can just as easily sneak something somewhere in the users PATH ahead of the real GPG...

        • Re:GPG is also a disaster and other rants (Score:5, Interesting)

          by zenyu ( 248067 ) on Monday September 22, 2003 @08:38PM (#7030138)
          Excuse me for my ignorance of how GPG is called, but isn't just loading an executable from your path subject to the same sorts of attacks (really, easier onces) than the LD_LIBRARY_PATH modification? I can just as easily sneak something somewhere in the users PATH ahead of the real GPG...

          I think the problem is that shared libraries are shared across users, so you just need to have a user account on the machine with debug access to mess with a library, while to change someone's path you need to compromise their account. The problem with this arguement is that if you have debug access you can mess with so many things that avoiding shared libraries isn't going to help much. The only thing it might do is force someone to crack X, pine, emacs or something else you are using to compose whatever you plan to GPG so while the system is compromised GPG can claim that their part of it wasn't.

          Moral of the story is don't allow security to depend on a development machine's pristine state and don't enable ptrace, or loadable modules for that matter, on a production machine that is intended to be secure.

    • GBDE (Score:3, Informative)

      by quantum bit ( 225091 )

      Oh, and while I'm ranting about the horribleness of Open Source security stuff, why is it that there is STILL no well-integrated filesystem crypto in any of the Open Source operating systems, including the security-oriented OpenBSD? No, loopback crypto kludges don't count at all.

      Check out FreeBSD 5's GBDE [freebsd.org] system. It's still relatively new and needs some polishing, but is improving rapidly. It's already quite usable.

  • CIPE is a toy (Score:4, Interesting)

    by Anonymous Coward on Monday September 22, 2003 @05:26PM (#7028786)
    He's talking about CIPE and pals...

    I remember when I installed Red Hat I went looking for IPsec .. I found CIPE thinking it was an IPsec implementation.. a quick perusal through the source code and docs made it appear to me that it was basically somebody's homebrew project designed with little regard for security. IPsec has its problems, depending how you set it up, but this was worst.

    The 32-bit CRC thing caught my eye as well. I'm no crypto export but I know enough about it to remember how CRC-32 is a weakness of the SSH 1 protocol.

    I have since set up freeswan and am happy with it even though I really don't understand IPsec that well I think it has been more closely scrutinized.

    So yeah, the author is probably right when he calls it the open-source PPTP... I don't see what it has to do with open-source or closed-source, although with open source it was easy for me (and the author) to gauge the quality of the code and avoid it.

    • Re:CIPE is a toy (Score:4, Informative)

      by jpc ( 33615 ) on Monday September 22, 2003 @07:08PM (#7029547) Homepage
      hmm, not so sure.

      First, the CRC32 problems only put it on par with ssh 1. Which is still in use by many people I suspect. ok it should have been fixed.

      The padding iisue just means that aes cant be used. afaik cipe doesnt let you change ciphers anyway. Its not that bad - the algorithms it uses are probably safe for a few more years. Plaintext size leaks small amounts of information, so it is not best practise, but not fatal. aes would be nice though.

      The message sequence issue (replay etc) is on the face of it rather bad, except that cipe is designed for carrying ip traffic. Repeating or removing udp messages is fine, and tcp messages do have sequence numbers. So I fail to see how that is a problem.

      And the key exchange is fairly irrelevant as it is basically a private key protocol. They key exchange stuff was an afterthought and I doubt if anyone uses it. Designing public key encryption is much harder and cipe should have stuck to private key.

  • You can't just slap together a security package. (Score:3, Insightful)

    by Meat Blaster ( 578650 ) on Monday September 22, 2003 @05:27PM (#7028788)
    Cryptographic programming is one of those disciplines that comingles heavy mathematics, electrical engineering, and programming in the same field.

    One can browse a manual on the topic and write an implementation that technically works (when paired with a similarly shoddily-designed decoder), but be fully unaware that the pseudorandom generator is just that. Or that the ones-complement portion of the crypto engine fails when X=0, weakening the whole thing by sixteen bits while not producing garbage.

    Unlike a crappily-designed game, it's a lot harder to spot when crypto goes wrong. And most of those thousands of eyes supposedly peering over the code aren't looking that hard.

    I'd still contend that commercial crypto has had more and bigger flaws overall, but he's right that the open source process alone isn't going to give you good crypto.

  • Nice posting a denied link.

  • Issues... (Score:2, Informative)

    by dnotj ( 633262 )

    #1 Links to URLs not on standard ports stink. I'm stuck behind a very strict http proxy.

    #2 Links to message lists stink to. The location of the content is not obvious. Maybe the offport link contains some valuable information.

    #3 I did find the message that is the topic of this post. The material in the message seem very "dated".

    .dn

  • Software popularity (Score:5, Insightful)

    by _iris ( 92554 ) on Monday September 22, 2003 @05:31PM (#7028832) Homepage
    The time it takes to fix software is inversely proportional to the popularity of that software. I know 0 people that use CIPE and vtun.
    • Exaclty!

      I don't know anyone running Linux using anything other than SSH/SSL or IPSec tunnels for VPNs.

      Demolishing a house of cards isn't exaclty a difficult task.

      Hell, the beta's for Red Hat Enterprise AW3 have IPSec tunnel wizards. IPSec is probably where it will all be at for a while -- it is lower down on the stack than SSH and while can be a bitch to configure, once done is pretty transparent to applications.

  • Ah.... reminds me of the early days. (Score:3, Insightful)

    by solios ( 53048 ) on Monday September 22, 2003 @05:33PM (#7028848) Homepage
    Back in the day, whenever I'd bitch about how window managers lacked basic functionality, how the default IP tools didn't do multiple hot-switchable configurations, about the lack of decent documentation in the distro, about some aspect of the application that didn't work, shouldn't work that way, or had TOO MANY OPTIONS.... the response was ALWAYS "dude. The source is THERE. FIX IT YOUR OWN DAMNED SELF." With "That's a FEATURE, not a BUG." being a close second. To which I'd usually reply "I'm an ARTIST, not a CODER," resulting in a flamewar about the quality of the Gimp, but that's a different story.

    Things like this will get fixed when the people maintaining the packages start doing the gruntwork that gets those little bits enterprise grade- in other words, doing the hard, annoying, pain in the ass shit that you pretty much have to get paid to do, because nobody wants to do it in their free time. Big bonus points to open source software companies for making a BIG effort to do exactly that. :D

  • Hot News (Score:4, Funny)

    by tarquin_fim_bim ( 649994 ) on Monday September 22, 2003 @05:33PM (#7028850)
    Unmaintained software........unmaintained.

    In other news, Bear shits in woods.
  • Maybe not the bugs that are found, but I think all code on average starts out with pretty much the same amount of bugs, quite simply because programmers aren't perfect. In time, they iron out the bugs and it gets better.

    That's why I hate it every time there's an exploit in a major package and some people go "Switch to our pre-alpha sourceforge package that's *so* much better and safer". Maybe because a bunch of crackers/hackers/developers (usually in that order) haven't looked it over and found the subtle

  • So some OSS crypto products suck... and? (Score:5, Insightful)

    by Coryoth ( 254751 ) on Monday September 22, 2003 @05:36PM (#7028890) Homepage Journal
    I'm pretty sure there are some pretty pathetic, sad window managers out there too. Some of the text editors are rather less than impressive as well. There are all manner of dodgy MP3 managements systems. OSS creates all manner of bad software because ANYONE can code something up and release it.

    The security and cryptography field just highlights the problem because there are so many opportunities to do something particularly stupid in those fields. Anyone can write a cryptosystem that they can't break themselves. Unfortunately a lot of people figure if they can't break it, then neither can anyone else...

    Jedidiah

    • Re:So some OSS crypto products suck... and? (Score:4, Insightful)

      by AntiOrganic ( 650691 ) on Monday September 22, 2003 @06:24PM (#7029230) Homepage
      I don't think it's fair to say that "OSS creates all manner of bad software because anyone can code something up and release it" because they're perfectly capable of doing that without giving you the source too. At least here we have the ability to see the problems and avoid that software rather than taking the author's word that it's SUPAR 1337, which is much better than finding out much too late that our new IP tunneling solution that we've deployed on a 10,000-machine corporate network needs to be replaced with something else, like some people probably discovered with the PPTP issue.

      Like is highlighted in the article, these problems with "dodgy" software tend to arise when the author decides to reinvent the wheel, but neglects the tire and the axle grease.

      Everyone wants to make a name for themselves by being the next Richard Stallman, rather than working on the established products with comprehensive peer review and years of code history. Why write new protocols that are doing the same thing that SSH is doing? It's nonsensical.

      There's usually very little real reason to create these abominations. If an existing project doesn't have a feature you want and you're capable of coding it, for God's sake, code it to work with the existing product. I'm willing to bet that the guys behind these protocols got flat-out laughed at by anyone doing real cryptography work, but still somehow felt that they were right all along.

  • my two cents (Score:4, Insightful)

    by jeffy124 ( 453342 ) on Monday September 22, 2003 @05:38PM (#7028903) Homepage Journal
    Linux in general is more popular than this project. That popularity gives it more eyes to keep watch on it, and shorter turnarounds when problems are found.

    As for this project (CIPE), I personally have never heard of it. Indeed, neither has the poster from that mailing list: A friend of mine recently pointed me at CIPE, a Linux VPN tool that he claimed was widely used but that no-one else I know seems to have heard of.

  • vtun and ssh (Score:5, Insightful)

    by nilsjuergens ( 69927 ) on Monday September 22, 2003 @05:39PM (#7028926) Homepage Journal
    Vtun is still far from being useless.
    Just turn off vtun encryption and use it via a ssh tunnel. That works very well (i use it for securing wifi) and uses a proven protocol.

    I also believe this is good practice and should be a widely accepted policy - re-use of good and proven software is not lame - it is crucial for easy, fun and secure software development. There really is no need for re-inventing the wheel.

    Now if only ssl were so integrated into the operating system that i could use select() on a ssl-socket created with socket(), and thus making writing of ssl-enabled apps as easy as non-ssl-enabled ones, that would be great!

    • Re:vtun and ssh (Score:3, Informative)

      by TheCrazyFinn ( 539383 )
      vtun+SSH Port forwarding is the standard for quick+dirty+secure VPN's. vtun is simply a tunneling protocol with some basic security, it is not a secure product in it's own right. Add SSH and it's actually reasonably secure.

      It also offers a couple of other advantages. Combined with SSH, it's actually secure when punching through a NAT'ing firwall (IPSec isn't since AH and NAT don't co-exist) and it's capable of tunneling at layer 2, so you can tunnel non IP network protocols (It can emulate a serial connect
    • Now seems like a good time to point out why any scheme using TCP over TCP is a bad idea [sites.inka.de].

      Of course, the author of that article went on to write CIPE, which is one of the problem protocols under discussion.

      I use freeswan IPsec [freeswan.org] for securing wifi. The biggest problem with IPsec is that it suffers from "committee bloat" and is very complicated to use. Freeswan partially mitigates this complexity by implementing only a narrow subset of the RFCs (in fact, it is not even RFC compliant, because they deliberately

  • So use a Linux IPSEC implementation instead (Score:5, Informative)

    by whoever57 ( 658626 ) on Monday September 22, 2003 @05:40PM (#7028928) Journal
    FreeS/WAN [freeswan.org]

  • openvpn is much better (Score:5, Interesting)

    by nirik ( 5709 ) <kevin@scrye.com> on Monday September 22, 2003 @05:40PM (#7028933)
    If you are looking for a good vpn package for linux, try openvpn:
    openvpn [sourceforge.net]

    It was created a while back when all the other linux vpn products were not that great, and it seems like thats still the case.
  • vtun was never designed to be totally secure. It even says so on the website. Still I admit, two years is a lot of time for someone to come up with something. Shame, cause it's a really nice program.

    Anyone out there up for the challange? (I'd try, but I'd have no idea where to even start!)
    • from the vtuns faq ** 1.19 How secure is VTun ?
      Well. VTun doesn't try to be the MOST secure tunneling software in the
      world, it tries to be fast, stable, rich of features, easy to use
      and secure enough instead.
      VTun uses Challenge Based Authentication and doesn't transfer passwords
      in clear text. Encryption module uses MD5 for 128 bits key generation
      and BlowFish algorithm for actual data encryption.
      There could be some weaknesses in key generation method, we will try
      to address them in future rel

  • Well put (Score:2, Redundant)

    by indole ( 177514 )

    One particular quote:

    Whenever someone thinks that they can replace SSL/SSH with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve elightenment...

    pretty much sums up the rest of the post.

  • Many projects arent aimed at production at all and thats all dandy in my book. If every piece of open source became mysteriously secure by accident and voodoo i would be much surprised. Ofcourse there will be insecure and shoddy apps but you know what?

    With open source the users can migrate without a penny to something more secure. The difference as i see it is that you can choose what authentication/web/shadowing/crypt you want by yourself and you are not in the hands of someone else. You are responsible f

  • from the VTUN page : (Score:4, Interesting)

    by painehope ( 580569 ) on Monday September 22, 2003 @05:49PM (#7029009)
    1.19 How secure is VTun ? Well. VTun doesn't try to be the MOST secure tunneling software in the world, it tries to be fast, stable, rich of features, easy to use and secure enough instead. VTun uses Challenge Based Authentication and doesn't transfer passwords in clear text. Encryption module uses MD5 for 128 bits key generation and BlowFish algorithm for actual data encryption. There could be some weaknesses in key generation method, we will try to address them in future releases.
    ...
    1.23 Can I use vtun over SSH ? Yes, via the port forwarding feature of ssh. Don't enable vtun's encryption as ssh does its own encryption. Also, make sure to select the tcp protocol as SSH can forward tcp but not udp. An example session might look something like this: home$ ssh -L 5000:localhost:5000 work.megacorp.com (authenticate if necessary) work$ vtund -s home_tunnel_config ... home$ vtund home_tunnel_config localhost

    Now, having said that, I use VTUN and haven't had any problems. But then again, I also have the boxen firewalled to hell and back, no services allowed but SSH from a few known hosts, no root SSH, etc. So even if you do crack my key, you're not getting much that will get you anywhere.
    While I don't consider it the most secure tool, it does the trick well enough for now. Kudos to the VTUN team, and kudos to Peter for his examination.

  • I've used vtun for years and years. It's always been a nice, easy system to set up.

    I also always turned off security on it - it's primary purpose was always to be a tunnel solution, not so much a security tool. What's more, I don't open any more ports on my server than I need to - I bet there are buffer overruns in vtun...

    I always tunel vtun over ssh. Problem solved.

    I need to look into openvpn (http://openvpn.sourceforge.net/).

  • Talk about stating the obvious! (Score:4, Insightful)

    by polyp2000 ( 444682 ) on Monday September 22, 2003 @05:58PM (#7029067) Homepage Journal
    Open Source or Closed Source, its just as easy to write insecure software, either way.

    The point is, that with open source you can see just how insecure or secure a particular product is by looking at the code.

    Open source is inherently no more secure than closed source software. The difference is people like "Peter Gutmann" can see what is wrong and be at the ready with suggestions how to fix it.

  • I think I see why these haven't been fixed. (Score:5, Informative)

    by RealAlaskan ( 576404 ) on Monday September 22, 2003 @06:03PM (#7029107) Homepage Journal
    From Freshmeat: CIPE
    Rating: 8.35/10.00 (Rank N/A)
    Vitality: 0.01% (Rank 4941)
    Popularity: 2.72% (Rank 1001)

    VTUN
    Rating: 8.55/10.00 (Rank N/A)
    Vitality: 0.02% (Rank 2787)
    Popularity: 2.69% (Rank 1017)

    Neither of these projects are dead, quite, but neither is terribly active, either. Sourceforge shows one developer for CIPE, for example.

    As an earlier post said, crypto demands skills which aren't generally available, in an unusual combination. Many competent eyes make bugs shallow. Many competent coders make bugfixes quick. It looks as if those packages haven't drawn the competent eyes and coders yet.

    Maybe Mr. Gutman's post will draw some good folks who are able to do the work to these projects. Or maybe it will inspire the maintainers to simply let them fade away. Either way, we're better off for his efforts.

    A third possibility is that folks will just not care. Gutman tells us:

    - These programs have been around for years (CIPE goes back to 1996 and vtun to 1998) and (apparently) have quite sizeable user communities without anyone having noticed (or caring, after flaws were pointed out) that they have security problems.
    This kind of thing needs to be fixed or abandoned; bad security is worse than no security
  • ... to use.
    I hope the flaws are fixed.

  • So what does he have to say about the freeswan IPSec implementation, especially when combined with iptables?

  • the conclusions mostly do not follow (Score:5, Interesting)

    by fermion ( 181285 ) on Monday September 22, 2003 @06:38PM (#7029329) Homepage Journal
    I think what this shows is that security is very hard to do. It is very hard to come up with a good protocol. It is very hard to code that protocol so it is secure. It is very hard to deploy the code so it is secure. The author is of course correct that security code should be left to those that are competent.

    The first big difference between OSS and commercial products is often that commercial products want to either invent a new proprietary protocol, or, for marketing reasons, push an obsolete protocol as a new innovated protocol. Both of these leave end users insecure. However, since everything is proprietary, there is no way for the user to know the level of insecurity. And, if we may drop names like in the article, Scheier lists a new company nearly every month who tries to push crap as security, though he has gotten so annoyed that he has skipped months of late.

    And to drop the name again, Schneier, has spent his time of late trying to convince people that security is so much more than protocols. The protocols must be implemented in code correctly and deployed correctly. Unless one is a huge national agency with a classified budget and decades of security experience, it is unlikely that one can create a secure product. It is much better to make the code public so that interested parties can investigate. It doesn't mean they will.

    The two of these combine in interesting ways in closed software. There are claims of 1,000,000 bit keys. There are situation in which security by obscurity is used as the first line of defense. There are situation in which the DCMA is used as the first line of defense.

    Which is just to say that conclusion #1 and #2 does not follow from the text. Just because one finds a few packages that are out of date in OSS, does not mean that finding a few updated packages in closed source software are more secure. Conclusions #3 and #4 are trivially valid, and applies to anyone writing software in any model. All programmer should take the advice to heart, especially if they want to design a right management system using closed protocols.

  • "Linux" Packages (Score:4, Informative)

    by pete-classic ( 75983 ) <hutnick@gmail.com> on Monday September 22, 2003 @06:53PM (#7029439) Homepage Journal
    It is eminently unfair to call these "Linux" packages.

    Of course, none of them are GNU packages, either . . .

    OTOH, tinc does have a linux.org homepage, but then it seems to not be "Demolished" by any reasonable definition. He says "This is a terrible way to use RSA, and usually compromises the key." and I'm no crypto geek, but I think what he means by "compromises" is "provides and avenue of attack that is mathematically simpler than brute force against the key" not "reveals the secret".

    So, two seemingly abandoned projects are suspect, and one relatively arbitrary (but Open Source!) package has a theoretical weakness.

    All that said, my question is: What has been demonstrated (or demolished)?

    -Peter

  • This is open source working, people (Score:4, Interesting)

    by ikekrull ( 59661 ) on Monday September 22, 2003 @06:59PM (#7029478) Homepage
    This guy, obviously with more than a few clues about security, is able to examine the products, right down to the source level, analyse the security provided, freely publish his findings and suggest improvements (even if all he suggests is 'scrap it', and something about skull-fucking with sound-waves.)

    This is great information, and while it might not reinforce the 'open source uber alles' message, it is very useful to anyone who might be considering working on these or similar projects, as well as anyone that uses them.

    Even if Mr. Gutmann says these products can't be completely fixed, at least the authors can improve them now based on his comments, and just because this guy says it can't be done, doesn't mean it is gospel.

    I say a big thank you to Peter Gutmann (a fellow kiwi, alright!) for taking the time to write this and help to improve the state of open source security products.

  • The Real Problem (Score:5, Interesting)

    by Effugas ( 2378 ) on Monday September 22, 2003 @07:22PM (#7029635) Homepage
    First of all, I've got a tremendous amount of respect for Peter Guttman, and not just because he's the author of the coolest quote relating to computer security of all time (if you can't find it in that essay, you're not paying attention). But...he misses the point.

    We do not have an effective method of running a stateless cryptosystem, but IP actually does require stateless operation. All these mini-systems that have sprouted up exist because of this.

    SSH(which, incidentally, violates Guttman's rules by using "the same key for encryption and authentication") and SSL(which utterly falls apart when the cert gets compromised) both run over TCP. TCP is not IP. TCP adds reliability, through error detection, correction, order management, and congestion management. That's all well and good, but sometimes I really don't care when I drop a packet. Voice traffic is a fantastic example -- by the time the retransmission is complete, the data is stale and irrelevant. But TCP will not only stop to retransmit, it'll hold up everything else while it does so, and even slow down the connection to be sure a dropped packet doesn't happen again.

    There are _many_ protocols which can accept these semantics. But there are many that cannot, and there's a bigger problem: By supporting those protocols that do not share the connection semantics of TCP -- DNS, VoIP, etc -- we end up being forced to carry either GRE or PPP packets over the SSL/SSH tunnel -- and inside these PPP packets, that are being carried by TCP, is more TCP.

    This doesn't work very well at all -- effectively, both sockets attempt to simultaneously adjust to changing network conditions, and since neither knows about eachother, they both screw up badly.

    All because we do not have a stateless cryptosystem that works. It may very well be that such a demand is impossible. Stateless cryptosystems can send a message and not only not prenegotiate a session key, but tolerate large number of dropped packets. Replay attacks need to be suppressed, but packets need to be able to survive high latencies. CPU load needs to be kept reasonable, but no message can rely on the asymmetric results of another.

    In short, normal cryptosystems are built to be inflexible to attackers; we do not know how to make them simultaneously flexible for networks. The reasons why should be obvious -- anything that can go wrong on the network, will go wrong because of an attacker. So telling everybody to use SSH/SSL is ultimately code for, "We just don't have the crypto to secure IP." And we know IPSec is a failure; if it hadn't been for VPN's, it'd be as rare as multicast and a hundred times more expensive.

    Solutions? I suspect short signatures will ultimately make the difference, as will better time-based protocols (at least for intra-admin-domain work.) But no matter how high my opinion is of Guttman, I cannot ignore he considers solved problems that fundamentally refuse to go away.

    Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com

    P.S. There is an immediately available VPN solution that's free and doesn't suffer from TCP-over-TCP effects. Look up Dynamic Forwarding for OpenSSH ... TCP is terminated at the forwarder, addressed using SOCKS4 or SOCKS5(>3.7.0), and forwarded to the appropriate destination on the other side of the tunnel. It's TCP _only_, but it operates completely in userspace.

  • Peter Gutmann and tinc (Score:4, Interesting)

    by gsliepen ( 303583 ) on Tuesday September 23, 2003 @04:55AM (#7032222)
    Peter Gutmann contacted us (the tinc developers) on September 15th, quoting the part of his writeup relevant to tinc. We exchanged a few emails since then. There are some points where tinc could certainly be improved (some of it already planned for 2.0), but we don't believe the "real problem" he mentions actually exists. We have told him our objections to his writeup, and asked if he could prove or make it more plausible that an attack on the authentication protocol is possible. He still hasn't convinced us.

    In some more detail: the 32 bit predictable IV might make the other 32 bits of the first encrypted block more vulnerable, but the other 32 bits of that block only contain part of a MAC address which does not reveal any important information. It does not compromise the other blocks AFAIK, and in fact a sequence number instead of an unpredictable random number is more secure according to Jerome Etienne, who has done a much more detailed security analysis of tinc in the past.

    The messages encrypted with RSA are indeed not padded, but padding is, AFAIK, only necessary when the message is shorter than the RSA key. In our case, the message is exactly as long as the RSA key.

    Peter Gutmann believes there is a possible MITM attack ("Chess grandmaster attack"), but hasn't shown us how, just that he believes it's there.

    Peter Gutmann also believes tinc has to be configured identically on each endpoint, but that is not true at all.

    We're still in discussion, and if we believe there is really a problem we will fix it. In his conclusion Peter says that everyone should be using SSL or SSH. We could, but I don't believe SSL is necessarily the be-all and end-all of encryption.

Slashdot Top Deals

If you aren't rich you should always look useful. -- Louis-Ferdinand Celine

Close