Linux Crypto Packages Demolished
Posted by
simoniker
on Mon Sep 22, 2003 05:19 PM
from the security-is-all-relative dept.
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
|
Log In/Create an Account
| Top
| 404 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
What a great Quote (Score:5, Funny)
(http://www.novacoast.com/)
"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
Re:What a great Quote (Score:5, Informative)
(http://www.davidgerard.co.uk/)
Re:What a great Quote (Score:5, Informative)
(http://www.less.com/)
http://www.glgarden.org/foreverman/brasseye.html [glgarden.org]
(if you're impatient, click "page 2" and search for "sound wave".)
Use the trustworthy stuff (Score:5, Funny)
Oh no! (Score:3, Funny)
(http://www.thundersplace.com/)
POPTOP (Score:3, Interesting)
(http://fmlug.org/)
Re:POPTOP (Score:4, Informative)
(http://www.bittern.o...y/Antinomialism.html)
L2TP replaces it, and MS seems to have got it right this time.
CIPE (Score:5, Informative)
(http://www.rigidsoftware.com/ | Last Journal: Saturday September 24 2005, @11:58PM)
Did I miss something?
Re:CIPE (Score:5, Informative)
(http://www.wirewd.com/wh/)
Re:CIPE (Score:5, Funny)
(http://spacebox.net/)
Given that, one would think industry strength implies insecurity!
Don't let my alias throw you off, I'm not about bashing Microsoft, but this was just too easy
thank you captin obvious (Score:5, Insightful)
Re:thank you captin obvious (Score:4, Informative)
(http://www.wirewd.com/wh/)
False (Score:5, Informative)
in 2002 and 2003.
Check their homepage:
http://vtun.sourceforge.net/
Maybe only small update.
Give this man a PhD! (Score:5, Interesting)
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:4, Insightful)
I thought I just explained the definition of "security". It's different from "safety". Check your local dictionary for more info: security is an assurance of safety.
You might be safe, but if you don't know it, you're not secure.
Re:Give this man a PhD! (Score:4, Insightful)
(http://slashdot.org/)
In this context I think "security" is a process of minimizing risks to acceptable levels for an arbitrary application.
If the public can't review something, they can't know it's safe.
So? 99.999% of the population can't determine good programming even if the source is open. I guess by your theory there is no secure software in use at the CIA or the NSA because "the public" hasn't seen the code.
The sanely paranoid won't take anyone's word on security, they need the ability to check it personally.
"The sanely paranoid" != "The public"
Only those using the software need to know it is secure. This can be accomplished whether the software is Open Source or not.
Re:Give this man a PhD! (Score:4, Insightful)
(Last Journal: Wednesday July 14 2004, @10:44PM)
i responded instead of modding you. Let me just point out that if the public is using it then it should be open source so that the neccasary non-corporate people (hackers) can take a look at the code and fix what is needed, in the case of microsoft they are saying "trust the people who we employ, and who depend on our products to make money" which is a very very bad thing to rely on.
The open source community might not be perfect, but its one hell of alot closer than any proprietary setup. (not to mention that the larger the OSS community gets the more people will be looking at the code, hence more security.)
the CIA and/or the NSA are bad examples of security in software. (as is anything in gov't) because politicians decide what gets done, and politiks do not mix well with software.
Re:Give this man a PhD! (Score:5, Insightful)
(http://slashdot.org/~Asprin | Last Journal: Wednesday November 05 2003, @03:24PM)
#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.
GPG is also a disaster and other rants (Score:4, Insightful)
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.
Debian to the rescue! (Re:GPG is also a disas...) (Score:5, Informative)
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?
Re:Debian to the rescue! (Re:GPG is also a disas.. (Score:5, Informative)
(http://www.pobox.com/~tqbf)
No, because GPGME is GPL, not LGPL, and all it does is make calls to the (GPL) GPG binary.
Re:GPG is also a disaster and other rants (Score:5, Insightful)
(http://web.mit.edu/stevenj/mosaic/steven.html)
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)
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)
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)
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.
CIPE is a toy (Score:4, Interesting)
I remember when I installed Red Hat I went looking for IPsec
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)
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)
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.
Re:Well then, fix it! (Score:5, Insightful)
If you read the article, his advice is almost every case is "Scrap this, go learn basic crypto, and try again." I don't know crypto at all, but I'm willing to bet that's good advice. And if so, why on earth should he take the job of re-writing CIPE? I think it's great that he's getting the word out that it's insecure. These are the things that should be public knowledge.
Re:Well then, fix it! (Score:5, Interesting)
(http://www.wirewd.com/wh/)
Sometimes the best thing a programmer in this situation can do is to just declare a piece of software broken beyond repair and just retract the sucker.
I mean, CIPE might have made sense before the widespread availablity of open-source, carefully crafted IPSec software. Now, your best mileage is to provide easy directions for how to build an existing, functional IPSec setup.
Software popularity (Score:5, Insightful)
(http://drew.intercarve.net/)
Ah.... reminds me of the early days. (Score:3, Insightful)
(http://amongthechosen.com/)
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.
Hot News (Score:4, Funny)
In other news, Bear shits in woods.
So some OSS crypto products suck... and? (Score:5, Insightful)
(http://jedidiah.stuff.gen.nz/wp/ | Last Journal: Wednesday April 04 2007, @02:51PM)
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)
(http://www.madtasty.com/)
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)
(http://slashdot.org/my/amigos | Last Journal: Sunday July 25 2004, @02:59PM)
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)
(http://www.efisto.org/ | Last Journal: Sunday March 30 2003, @11:48AM)
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!
So use a Linux IPSEC implementation instead (Score:5, Informative)
(Last Journal: Thursday September 30 2004, @01:33AM)
openvpn is much better (Score:5, Interesting)
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.
from the VTUN page : (Score:4, Interesting)
(Last Journal: Wednesday October 16 2002, @11:21PM)
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
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.
Talk about stating the obvious! (Score:4, Insightful)
(http://www.polyprecords.com/ | Last Journal: Friday October 03 2003, @02:20PM)
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)
(http://geocities.com/nelstomlinson | Last Journal: Wednesday January 22 2003, @01:19AM)
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:
This kind of thing needs to be fixed or abandoned; bad security is worse than no securitythe conclusions mostly do not follow (Score:5, Interesting)
(Last Journal: Thursday May 03 2007, @11:34AM)
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)
(http://hutnick.com/ | Last Journal: Monday March 12 2007, @09:15PM)
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)
(http://members.xoom.com/ikekrull/)
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.