Slashdot Mirror
Linux Crypto Packages Demolished
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.'"
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
I only use the Cyrillic Projector code. No one ever will crack that.
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?
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.
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.
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!
-- Having problems sending big files over the net? Try out Efisto (http://efisto.org)
If you are looking for a good vpn package for linux, try openvpn:
openvpn
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.
Of course it'll have a similar number of holes. After all, there's nothing about OSS that makes the software fundamentally more secure. BUT:
1) These holes are far less likely to be in the base operating system implementation, as the OSS mantra is generally to put as much logic in user-space as possible.
2) These holes won't be covered up and released only after the vendor has decided to let us know about them.
3) These holes will be fixed up very quickly (in general, anyway), in individual patches or point releases, without onerous licenses attached to them, and without fear that the release might break the rest of my operating system.
4) Because OSS products use open standards, if one particular package is simply too insecure, at least I can change to another product and have things interoperate (eg, switching from Sendmail to Qmail/Postfix/MTA-de-jour).
Instead of making yourself look so great by "demolishing the security," why not offer the fixes?
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.
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?
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 securitySee what I've been reading.
Those GNU folks are just evil; that's why they would never agree with something like the Vorbis BSD license.
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.
If a thing is not diminished by being shared, it is not rightly owned if it is only owned & not shared. S. Augustine
VTun has been updated
in 2002 and 2003.
Check their homepage:
http://vtun.sourceforge.net/
Maybe only small update.
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.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
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.
... 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.
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