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.'"
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.
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.
He's talking about CIPE and pals...
.. 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.
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.
The Reiser4 filesystem is supposed to allow for encryption plugins once it is released (later this year?).
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.
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.
If you ignore automated worms and mail viruses, Linux/Unix has traditionally had far more attacks than Windows. Even a few short years ago, you could put a unpatched Windows box on the Internet and would be largely ignored. Not the case with something like RedHat Linux, which would be scanned and hacked within hours.
The "skript kiddies" like hacking Linux & Unix because it's "elite" and has usually has tons of tools like compilers installed. (Also, the Unix community was far ahead of Windows people with "open disclosure", which meant it was really easy to create hacks.)
Anyone else remember the t-shirt "My other computer is your Linux box". Little joke at the expense of the n00bness of most Linux users.
Oh, and RedHat already does nearly weekly security updates and has done so for years.
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.
PC moderators can suck my White pierced, tattooed dick. If you think pride == hate, s/dick/Aryan meat mallet/g.
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 smart enough to detect a password prompt and bring up a dialog for the user, I'd really like to know about it. Actually, if anyone knows of any good GUI mount programs *period*, I'd like to see them.
Other than that, my crypto filesystems are very easy to use. All I did to set it up initially was check a box and fill in a passphrase.
I'd go one step farther.
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.
Gentoo Sucks
I, for one, feel a helluva lot more comfortable when not only me, but others well-versed in the technology are privy to its inner workings and have verified its core paradigms are valid.
This reminds me of those old mechanical G&S security locks we used on top secret stuff. You could examine the lock all you wanted. You could take it apart and reassemble it. You could know exactly how it works. And still be helpless if you found yourself on the wrong side of a locked lock.
I have some of those old G&S locks on my house that I bought from Surplus at the Aerospace contractor I used to work at. I know nobody's coming through the back door without first destoying the door, but in the event I lock myself out of the house, I can go around back and dial myself back in.
To me, Top Security is security that everyone has looked at, yet has no idea how to crack given they know every detail of its implementation, and find themselves helpless if they are "locked out". You can rest assured that on any "security based on obscurity" paradigm, someone out there will know the "obscurity" part and will have free reign.
The open-source system is working. Now everyone, not just the crooks, know where the vulnerabilities are, and those vulnerabilities should be addressed post haste. "Faith" is for religions, not for assurance you are running a secure system.
There is no reason why just the crooks will know how to compromise a secure system. NO-ONE should know how to compromise a secure system.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
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
Freshmeat activity level is not necessarily a good indicator for CIPE, which comes bundled with some linux distro. I know quite a few people who were aware of CIPE weaknesses and still used CIPE for exactly that reason - it came bundled.
3.243F6A8885A308D313
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.
I gots ta ding a ding dang my dang a long ling long
You should try Perl.
You set up a socket, via either IO::Socket::INET, or IO::Socket::SSL (which of course requires a bit more mess to pass the keys, etc)
Whatever method you use, you can use IO::Select on it.
If this works in Perl, it can't be impossible to make some wrapper to make SSL as transparent in C as it is in Perl.
How about OpenVPN?
It's usually used to tunnel IP, using UDP datagrams on port 5000 to get there. The encryption and authentication happens with OpenSSL.
You can also make it go over TCP if necessary, and it can bridge Ethernets if you need more than just IP.
All of this happens in userspace, since it uses the universal TUN/TAP driver which is already in the mainline Linux kernel. It lets you avoid a bunch of evil things like the complexity of IPSec or the TCP over TCP problems with a PPP-SSH tunnel.
It's obviously written by someone with a few clues, since it will drop root and become a specified user and group if you like. It'll also chroot into some empty directory beforehand if you put that in the config file.
I first heard about it here, so I'm giving back by mentioning it again.
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
The problem with Einstein is that he was just an armchair physicist.
Why didn't he just shut up and do something?
Can someone tell me when expertise, perception and wisdom became "worthless"?
"Excuse me sir, but did you know that your door lock is faulty?"
"Hey, don't give me none of that talk mister. Just shut the hell up and fix my lock. OK?"
"Listen. . . asshole. I didn't design the lock, I didn't make it and, more to the point, I'm not the jerk who put it in your door. It's your design, your lock and your door. You fix. Now FOAD."
Open source is about sharing, not about making the other guy responsible for your cockups.
KFG
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.
Except, gee whiz, setting up an SSL connection is not identical to setting up a TCP connection. For one thing, you're supposed to check the certificate chain, which is something that requires your application to throw some logic behind. This is not functionality that can be automagically subsumed into the operating system (at least, not without inventing another API to do it). While OpenSSL may not be pretty or particularly well-documented, the API does cover all the bases.
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.
When I start selling you my project as shinola, you can tell me that it's a shitty product. Until then, you're welcome to contribute. If you just want to criticise, then I'll thank for your input, but advise you to calm down and take a chill pill.
Well, Peter Gutmann did provide useful insight for the programmers involved in these open source projects. What frustrated him was some of them ignored him, or simply did not know enough about security to understand his comments. That is the kiss of death for these projects IMHO.
He contribued far more insight to these projects than dozens of inexperienced programmers did previously.
Anybody using my project is liable to be doing so because they enjoy playing with it as much as me, not because they're relying on it for a critical application.
Sorry, I don't just use open source software for fun and enjoyable, I use it to get things to done in the real world. You are basically taking a cop-out, either your project (at the current time) is secure or it is not. If it is not secure, don't pretend that it is.