Slashdot Mirror
Bug In the GnuTLS Library Leaves Many OSs and Apps At Risk
New submitter williamyf writes "According to this article at Ars Technica, '[A] bug in the GnuTLS library makes it trivial for attackers to bypass secure sockets layer (SSL) and Transport Layer Security (TLS) protections available on websites that depend on the open source package. Initial estimates included in Internet discussions such as this one indicate that more than 200 different operating systems or applications rely on GnuTLS to implement crucial SSL and TLS operations, but it wouldn't be surprising if the actual number is much higher. Web applications, e-mail programs, and other code that use the library are vulnerable to exploits that allow attackers monitoring connections to silently decode encrypted traffic passing between end users and servers.' The coding error may have been present since 2005."
The Ars side widget is broken, perhaps they don't want me to see the Ars articles until they have time to approve their copies here on slashdot...
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Posting to undo moderation.
No, I can't explain how, but it's pretty obvious.
"Open Source Software is more secure because the code can be reviewed."
That's why this bug has existed since 2005. gg, guys. Thumbs up.
NSA? GCHQ? The norks? No, the Syrians?
...who has been surreptitiously using GPL'd code in their proprietary stacks...
Downmod this Micro$hit shill!!! How dare he spread FUD about free software. It's perfect and bug-free because of the many eyes auditing the codes!
Thank god it is in gnuTLS that is not used by any applications serious about security. Just checked, only printer drivers seems affected in my Debian installation.
has nothing to do with it
Just waiting for Microsoft's "Goto Fail" bug to surface. It may be too early to thank Snowden, but I'm starting to think I will have to at some point.
Both these bugs are caused by people using 'goto' like morons. Using 'goto' should start throwing compile-time errors to start forcing people off this relic of flow control.
From February 16 2008: Howard Chu of OpenLDAP: GnuTLS Considered Harmful
Looking across more of their APIs, I see that the code makes liberal use of strlen and strcat, when it needs to be using counted-length data blobs everywhere. In short, the code is fundamentally broken; most of its external and internal APIs are incapable of passing binary data without mangling it. The code is completely unsafe for handling binary data, and yet the nature of TLS processing is almost entirely dependent on secure handling of binary data.
Incredible that GnuTLS is used anywhere at all. It's just mind boggling.
I have always been critical about that conventional wisdom of "With enough eyeballs, all bugs are shallow".
I contend that is inacurate. With enough QUALIFIED AND MOTIVATED eyes, all bugs are shallow, and sometimes, some FOSS project lack enough Qualified eyes.
This bug, the KDE one, or even the Metafile bug in windows (and more importantly in WINE) among many others, show that many eyes are not enough.
Again one needs MOTIVATED AND QUALIFIED eyes AAAAAND good QA and test cases.
Cheers
*** Suerte a todos y Feliz dia!
The bug requires a carefully-crafted certificate. That certificate will verify as valid and trusted when it should not be. The connection will still be secure, it will just be with an untrusted person.
So basically it allows a very dedicated attacker to forge a cert and become a MitM attack.
We all know governments have done this for years. It is widely known that root CA certificates have been violated by spy agencies. A few searches on Google will show bunches of news stories where attackers (all types, government attackers, ID theft attackers, etc) have made fake certificates, abused the CA model, and engaged in similar MitM attacks to what this allows.
SSL/TLS communications are just as secure as they always were. If you have personally verified and trusted the certificates the attack wouldn't work, it is only when your trust model allows a cert that you don't personally trust to be used in authentication, and even then it still allows a secure connection but to a wrongly-trusted individual.
The flaw is the trust model and using a cert that you don't personally trust to be valid, which is a well-known issue.
//TODO: Think of witty sig statement
I'm not sure if only "many eyes make bugs shallow" is enough, but that also professional, thorough code audits (like OpenBSD does) are needed to produce the most secure open source software. Any comments?
"given enough eyeballs, all bugs are shallow"
Apple had their goto bug in TLS for about 18 months before they spotted it.
GnuTLS and therefore Linux has had their goto bug in TLS since 2005 (9 years) and it's only been spotted now as a result of the bow wave from Apple's disclosure.
First, and yet another OSS-releated security risk :(
At least they are rare enough that it is news worthy. As compared to Windows where new exploits hardly ever get any attention because they are so frilling common as to be passé.
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
Mageia 4 has already patched GnuTLS libraries yesterday.
Testing is hard. The tools you have make it even harder.
How do you build a bad certificate? Fuck, using the openssl tools is hard enough. Does anyone who uses them really understand WTF is happening? I know I don't - I just follow the instructions.
How would you go about building a bogus cert? Beats me. I'm pretty sure you can't do it with the standard tools. And who the heck is going to write their own cert building tools?
And yet, this stuff is at the core of transport security.
Hot on the heels of Apple's SSL/TLS implementation "flaw" across all stacks, and the Snowden revelations of NSA infiltration for weakening crypto?
You don't have to be wearing Tin Foil, just to become a little suspicious...
"Flyin' in just a sweet place,
Never been known to fail..."
Gnu way this is Gnue. Can't be Gnue. All those eyes, Gnuw and old, looking at this not Gnuw code, and Gnu one spotted anything. Wha? Yeah, buddy, Fuck Gnu Gnoo!
...as to be passé.
I do not think that word means what you think it means.
This is why you should always roll your own SSL scripts in php like the guy at Magic the Gathering Online Exchange did.
Some drink at the fountain of knowledge. Others just gargle.
An awful lot of stuff links to it. Browsers, flash, everything that dials out uses it on xubuntu. Are you saying that they are linking to it, but not using it? Or are they linking to it and then its using a wrapper to openssl.
xubuntu appears to depend largely on the package that "everybody knows is shit".
This does not make me happy.
Because if they were, the headline would have been zOMG mac and iOS not safe !!!!!!!11!!!!
# aptitude why libgnutls26
i wget Depends libgnutls26 (>= 2.12.17-0)
#
In other news, open source code which few people care about does not receive adequate review.
Thanks Obama.
This bug wasn't found from being open source. Those "many eyes" missed this bug for nearly a decade. Security testing tools uncovered incorrect validation behavior in the compiled library, just like they would with a closed source library. The only difference is that the public can see the incorrect code and correct it immediately; that is what you should be citing as an advantage of open source.
GnuTLS in an independent TLS implementation, i.e. not an OpenSSL wrapper. It was created for the usual bad reason something with GNU embedded in the name is created; because FSF licenses aren't perfectly compatible with <insert some non-FSF copy-left> license, in this case OpenSSL's license(s).
As far as quality goes, I've never used it, but I doubt it's worse than OpenSSL. Because the OpenSSL "API" is one giant WTF.
The OpenSSL license is not compatible with the GNU General Public License.
One thing I found interesting about the comments on Ars Technica about this article is that all comments regarding the (apparent) fallacy of open source allowing quick detection and turnaround of bugs tends to get very highly positively moderated, whereas the ones that argue that closed source software tends to limit the detection of such bugs and encourages sweeping detected bugs under the rug as much as possible get negatively modded or labelled "controversial".
One person even said this:
Said comment was modded quite well. Yes, things like this get a lot of attention and look bad for the open-source movement, but keep in mind that open-source/free software is fully transparent. No-one can hide the details with FOSS, something that is far easier to do with closed source software. That level of transparency make it appear as though open-source has more bugs for longer. No-one outside of Microsoft and very select partners are able to audit Windows or Office. And yet the closed-source software is more secure?
It boggles the mind a tech site like Ars Technica can be so pro-closed source and anti-open source despite what I'd assume to be populated with geeks who should know better.
Account abandoned. I can't fucking spell for shit and Slashdot doesn't even allow time-limited edits of posts. Plus you'
Is everyone racing to change their passwords?
I guess i should stop trolling #osx now then.
Nested blocks are refactorable into smaller functions.
And the program eats the function/method/message call overhead, the overhead of passing all local variables as arguments, and the overhead of constructing and destroying an object through which to return multiple values from each function call.
Try to remove that library, and you find that most of the critical software depends on it.
May it also be, the "coding error" was not an error at all, but a deliberately introduced bug? Government agencies always wanted to read our — and each other's — communications. Sometimes even for legitimate reasons...
In Soviet Washington the swamp drains you.
Everything is vulnerable. its just a matter of how.
---- Booth was a patriot ----
So when Apple's proprietary encryption software suffered a problem, Apple users could do nothing but wait for Apple to deliver a fix; there's nobody else that are allowed to fix Apple's proprietary software but Apple. And when that fix ostensibly arrived, Apple users had to hope it wasn't bundled with some malware too (as is often in proprietary software).
This bug was caught during an audit—"The vulnerability was discovered during an audit of GnuTLS for Red Hat.". Nobody but the proprietor can audit proprietary software. But with free software, users have the freedom to audit the code they run, patch that code, and run their patched code; users can choose to fix bugs themselves or get someone else to fix bugs for them. And users don't have to always trust the same people to do work on their behalf. Users can also choose to wait for a fix to be distributed, and then they can choose to check that fix to make sure it doesn't contain malware. For all we know some users have long spotted and fixed this bug in GNUTLS. Since all complex software has bugs bugs are unavoidable. We're better off depending on people we choose to trust. Software freedom is better for its own sake.
Digital Citizen
Much of the problems with overhead are obviated by inline functions.
...as to be passé.
I do not think that word means what you think it means.
"no longer fashionable; out of date"
Seems appropriate. They were explaining how it's not "fashionable" to report on something so common.
yeah, it'll be ugh... rolled out to ughm all the software that uses it by a central package management solution and update mechanism.
The GPL has an exemption for linking with libraries that are part of the operating system.
OpenSSL is not part of the "system libraries" on all platforms. Programs would have to have some sort of shim layer to use either OpenSSL on platforms with it or something else on platforms without it. If you distribute a client-side application designed for POSIX-like systems, most people aren't going to be willing to switch to a Mac or install Linux or FreeBSD in VirtualBox just to run it. (Windows is still preinstalled on the vast majority of desktop PCs sold in industrialized English-speaking countries.) And if you just distribute a VM with the operating system and your application pre-installed, you lose the ability to take advantage of the "system libraries" exception in the GPL.
Also, there are libraries which mimic OpenSSL's API, at least the most prominent parts. For example, NSS, CyaSSL, etc.
CyaSSL is GPL, and NSS is MPL/GPL disjunction. I imagine NSS has plenty of trained eyeballs looking at it because of its use in the Firefox browser and Firefox OS. But I'd never heard of CyaSSL before today, which casts doubt on how many trained eyeballs have been looking at CyaSSL.
And at the end of the day, no open source SSL library gets hammered the way OpenSSL does, especially server-side.
Would you say NSS gets hammered client-side?
So can we all get on the bandwagon with Fedora and start using NSS instead?
http://fedoraproject.org/wiki/...
ASIDE: Your point is mute [look up "moot" before attempting correction. 8-) ]. Enough is enough, and any less is not enough. That's the definition of enough.
Consider: "If you eat enough pudding you'll die"... the only test case is to keep eating pudding till you die. If you stop before you die you didn't eat enough. 8-)
Now the point that all eyeballs are not equal is fine and obvious. It only takes one metaphorical eyeball, connected to the correct brain, to find a bug. So one is enough if the rest of the configuration is suitable, and an infinite number are not enough if they lack the context.
The real difference between FOSS and others is not the quality of the eyeballs but the opportunity for the correctly quipped eyeball to fall on the relevant bit. In closed source applications the right post-eyeball configuration would have to first be part of the set of allowed eyeballs, and it would likely have to be actively paid to look for the bug directly or indirectly since the limited herd of eyeballs all have their assignments.
Pretending that the better solution (FOSS IMHO) is unworkable because it's demonstrably imperfect ignores the fact that the far less functional (NON FOSS IMHO) has a demonstrably worse track record. That comparason and derision is just "false dichotomy" and kind of an example of, perhaps, why you aren't the set of eyeballs in charge.
In non-FOSS circumstances virtually all eyeballs lack the context to find and fix problems because they lack access to the source.
So your argument fails because it implicitly argues against exposure, or argues that exposure isn't enough if the right people aren't looking. The failure isn't one of fact but of position. You offer no counter proposal. You are pissing on the model that exists but offering no alternative. In short you are engaged in venting of some sort but you are apparently not one of the set of eyeballs ready to offer solutions.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Snowden:
(v) Adding a bit of code, hardware, or operation you know you shoudln't because an authority requires you do so.
"Hey honey, I'll be late for dinner, I have to snowden the latest release of firefox."
(n) the sneaky bit of intrusive technology
"Hey what's this bit?" "Shhh, that's the snowden."
I know he was the wistleblower, but we should enshrine his deed and the knowledge that this is happening using his name in memoriam.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Nice to share with me......
Gtk links to it for some reason, so any distro XFCE of Gnome based would likely have trouble removing it.
And your's is just rote Dijkstra cargo cult. Really.
Use the tool that fits. Chose intelligently (yeah, that's the hard part).
http://xkcd.com/292/
Yes, gotos are really that evil.
First, and yet another OSS-releated security risk :(
At least they are rare enough that it is news worthy. As compared to Windows where new exploits hardly ever get any attention because they are so frilling common as to be passé.
Well, Slashdot seems to report on every vulnerability popping up on my Apple watchlist (often more than once), but not on all popping up on the RedHat watchlist. Draw your own conclusions from what you just said.
Of course news about a fake are Fake News.
First, and yet another OSS-releated security risk :(
At least they are rare enough that it is news worthy. As compared to Windows where new exploits hardly ever get any attention because they are so frilling common as to be passé.
Well, Slashdot seems to report on every vulnerability popping up on my Apple watchlist (often more than once), but not on all popping up on the RedHat watchlist. Draw your own conclusions from what you just said.
Forgot to mention: Apple's TSL-bug was also open source.
Of course news about a fake are Fake News.
Since all machine code is potentially brittle, the argument for using "safety aware languages" is itself brittle. For instance, Ada is safe because it doesn't allow deallocation unless you use ada.unchecked_deallocation(), or in the alternate, build nothing on the heap, or just hope that the Ada implementation has garbage collection, or..., or... etc.
_Someone_ has to do the work to protect whatever the brittleness is at issue.
For years I have used "struct Buffer { char * start, char * end};" instead of just char * string. (thing.end-thing.begin) is faster than strlen() and the constraints are always present. I've got a library full of simple bits that make this work (a wrapper around write(2) and read(2) for example).
Bad code can be written in any language. Java is safe? Well kind of, until you start making circles of referencds and losing them. sounds harmless unles there is a task and open socket in that circular reference and you've left a link back to some structure so that the socket is now able to access some nonsense.
The best tools in the worst hands are far worse than the worst tools in the best hands. Yelling for tools is a specious argument. Someone has to do the work, and that someone may well bone the job.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
The linux kernel is full of gotos. Assembly is bereft blocks and that sort of structure. So "goto" isn't the source of all evil.
Consier this example of the linux goto paradigm below. When taking locks and establsihing component preconditions you can write an optimal routine that does the stepwise creation, and includes the non-conditional cleanup. Then skipping the cleanup if all the parts succede. The example below is trivial, but when it comes to preserving locking orders it solves a hard problem very simply. And if you check out the generated code its very efficent. More so if you hint the compiler that the success case is most likely for each conditional.
So take the simple example and imagine you are building something complex like a network request with data and metadata buffers and the actual request structure itself et al... as the number of parts grow the number of bizarre else conditions you have to use to do stepwise cleanup become bothersome repetitions of code. Its even worse if it's part1 _or_ part2 along with part3 etc. Complexity and repetition of phrases in the elses is plenty of reason to use goto.
complex_thing * hard_thing() {
complex_thing * retval = 0;
thing_pt1 * pt1 = 0;
thing_pt2 * pt2 = 0;
if (pt1 = generate_first()) {
if (pt2 = generate_last(pt1)) {
if (retval = generate_final(pt1,pt2)) {
goto success;
}
}
}
if (pt2) cleanup_last(pt2);
if (pt1) cleanup_first(pt1);
success:
return retval;
}
Simply put, there are times when a well-placed goto with a clear purpose and precondition can simplify code and accelerate execution.
Do I use a lot of gotos? no. Probably six C/C++ gotos in the last fifteen years. But when they are the correct tool to use, they can be magical.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Almost no language takes the step to rule out gotos. Quite the opposite, actually, they added it back with a new name, specifically for the purpose it was used by Apple (and other places like the Linux kernel) - skipping to an error handler.
The new name is "throw", and it would have exactly the same problem.
Actually, anything would have the same problem, even a "success = true", because the problem was the same line being repeated twice, and the second one not being dependent on the "if" statement.
Where are my mod points, when I need them...
"I know two people who claim to understand the OpenSSL code - and one of them is clearly lying" - PHK, FreeBSD developer and author of Varnish.
So much for the eyes being concentrated on OpenSSL.
Ok! Ok! I must have, I must have put a decimal point in the wrong place or something. Shit. I always do that. I always mess up some mundane detail.
How many eyeballs did GnuTLS have?
If no-one uses it, there are no eyeballs. Thus no review.
Linux doesn't use GnuTLS in any way. Distributions using Linux might.
Thanks for playing. Better luck next time.
Using GnuTLS avoids the licensing issues that can arise from employing the more common OpenSSL package. For this reason, certain packages such as OpenLDAP are compiled with support for GnuTLS instead of OpenSSL in recent releases of Ubuntu.
In fact, on one of my Ubuntu 13.10 systems I ran ldd on /usr/bin/* and /bin/*, and found many many binaries that link in GnuTLS.
"Ahh! I see you're in that indeterminate Schrodinger state where - oh, uh
Is that really seriously a question?
Yes. In comments to various articles, you might be surprised at how many people ask questions like this: "Why are people still using HTTP at all instead of self-signed HTTPS?" Then they go on about something called "key continuity management", where seeing the same certificate as on the last visit means that no new MITM has been introduced, but that doesn't help if you're MITM'd from day one. The "Perspectives" project uses route diversity to root out MITMs, but that doesn't help if the MITM is on the server's upstream.
Seem to remember an update to gnutls for this problem! http://www.ubuntu.com/usn/usn-... USN-1752-1: GnuTLS vulnerability and a standard update fixes it! Whoopty doo! Kind of why I like that Ubuntu doesn't wait for an arbitrary day of the month to issue updates and patches!
He's not dead...yet!