Slashdot Mirror
Not Just Apple: GnuTLS Bug Means Security Flaw For Major Linux Distros
According to an article at Ars Technica, a major security bug faces Linux users, akin to the one recently found in Apple's iOS (and which Apple has since fixed). Says the article:"The bug is the result of commands in a section of the GnuTLS code that verify the authenticity of TLS certificates, which are often known simply as X509 certificates. The coding error, which may have been present in the code since 2005, causes critical verification checks to be terminated, drawing ironic parallels to the extremely critical 'goto fail' flaw that for months put users of Apple's iOS and OS X operating systems at risk of surreptitious eavesdropping attacks. Apple developers have since patched the bug." And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.
Who uses GnuTLS over OpenSSL anyway?!
This if nothing else, should show everyone it's time to switch to Windows, the OS immune to exploits.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
The impact of this bug does not compare to the goto fail bug. Most Linux distributions use OpenSSL for TLS. Even if a program links to GnuTLS, it may not use GnuTLS for certificate validation, and if it doesn't, then it's not affected by this bug (one example is Google Chrome). It's not like iOS where everything is required (by App Store rules) to use SecureTransport.
My distro patched this over a month ago.
Il n'y a pas de Planet B.
that Apple took notice of some accusations that the NSA managed to modiy some open source codebases, reviewed all code that was checked in at about the suspicious time frame, and found the "goto fail" bug that way. No idea whether this is true, but I'd be curious who checked in this bug.
Is anyone other than Debian zealous enough to use GnuTLS?
I rarely agree with Howard Chu of OpenLDAP fame, but... http://www.openldap.org/lists/...
> Most Linux distributions use OpenSSL for TLS.
> Even if a program links to GnuTLS, it may not use GnuTLS for certificate validation,
> and if it doesn't, then it's not affected by this bug (one example is Google Chrome)
Agree. I've ran through everything that linked to gnutls on my distro (Arch) and although there's
quite a lot of binaries that do, most of those do not offer TLS connections (or any network connectivity at all), so my
guess (without knowing GNuTLS at all) is that they use some other feature offered by the library.
Of those that I know actually capable of SSL/TLS connections, all (also) link to OpenSSL.
So without making a definitive statement, AFAICT this should have near zero impact on GNU/Linux.
And use OpenSSL. As awkward as it may be, it doesn't have the design flaws that GNU TLS does.
Are you trolling for an Apple-vs-Linux flame war? do you have a zealous attachment to Apple? or are you just dull?
1) This is old news, and the /. has already reported on it;
2) Hardly anything uses the GNU TLS library, and for the same reason people have been advising against Apple's rewrite of security libraries: because it's better to use something that's had over a decade of development and review and is widely deployed across a series of platforms;
3) You're arguing about the heterogeneity of the Linux platform as if it's a bad thing, while in fact this acts in Linux's favour. Even though the GNU project might like people to use gnutls, distros have chosen not to. Apple either discourages choice or makes it impossible, depending on what exactly you're targeting, which is why everything was affected.
Fixed at the beginning of March.
Example: http://advisories.mageia.org/MGASA-2014-0117.html
"Nothing to see here. Move on."
Create a library with that name that does nothing, or logs errors for any entry points. Why is something being shipped that is insecure. I understand that the builds have to be changed. But the library could be replaced with a skeleton right now, can't it?
And maybe we would see that its not quite as in-active as people think.
And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.
Gee. it sure is a problem that Red Hat, Debian, or Ubuntu couldn't just, you know, fix the bug and recompile the source code. Oh wait, they already did
FTFA
GnuTLS developers published this bare-bones advisory that urges all users to upgrade to version 3.2.12. The flaw, formally indexed as CVE-2014-0092, is described by a GnuTLS developer as "an important (and at the same time embarrassing) bug discovered during an audit for Red Hat." Debian's advisory is here.
Of course you blithering idiot, why do you think we have all this bloat lying around, if not for your protection?
... whatever
Create a library with that name that does nothing, or logs errors for any entry points. Why is something being shipped that is insecure. I understand that the builds have to be changed. But the library could be replaced with a skeleton right now, can't it?
And maybe we would see that its not quite as in-active as people think.
There are two distinct part of SSL/TLS; encryption and authentication. In this case it's only the authentication portion that has an issue, not the encryption portion. There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).
As for why GnuTLS exists, AFAIK it's mainly because of licensing issues -- compiling a GPLv2+ program against OpenSSL gets into licensing troubles, so there needed to be a GPL compatible alternative.
Please define "as quickly as desired". Debian was fixed on the 3rd of March which is the date of the Debian Security Advisory, that's pretty quick to me. I wonder exactly why this article pops up now, when it's been a long time we've been all patched.
The difference is that with closed source, the only exploits that are discovered by third parties and get fixed are those that have already been exploited, and already resulted in vulnerable systems.
With open source, exploits can potentially be discovered and reported by other parties *before* the exploit has actually ever been used, meaning that a fix is available at the same time that the exploit becomes public knowledge, and anyone who updates as soon as such an exploit becomes known has a higher level of confidence that their system will have not yet been compromised. The very fact that open source may also make it easier for a third party to find a way to exploit a previously unknown vulnerability also makes it easier for a third party to take action that will lead to the issue being corrected.
With open source, such critical bugs can and actually *will* be fixed, a sufficiently technically competent individual could even do so themselves, where with closed source, absolutely everyone is at the whim of the development team's schedule.
File under 'M' for 'Manic ranting'
Free/Open code is a necessary but not sufficient condition for security.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
and the blue screening of classic windows provides a hard shield against any rogue processes owning the machine for too long
There are two distinct part of SSL/TLS; encryption and authentication. In this case it's only the authentication portion that has an issue, not the encryption portion.
Unauthenticated public key encryption is useless against an active attacker (one able to modify traffic, rather than just eavesdrop on it).
There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).
Huh? Even for SSMTP, certificates can -- and must! -- be checked.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Now, who was this comment for? Half the stories generate complaints about obcure acronyms and lack of context in the summary, but you manage to throw that in?
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
Yes its used, but only sometimes. Only for that mail stuff, and hey maybe only if someone else is handling authentication because we know thats broken. And we need the stuff there for legal reasons and we need it there as an alternative. Just in case we need to use it, even though we know its broken.
So tell me, why cant we have the parts we know are insecure issue a log each time they are run?
This story should prove once and for all that ... "open source" does not provide any different level of security than closed source.
Um how? It proves that OSS is not perfect. No one ever claimed otherwise. An isolated incident proves nothing about the reltive security of the two.
OpenBSD (OSS) has had a couple of security flaws over the years. Windows 95 also had "some". Doesn't mean they're equally secure.
SJW n. One who posts facts.
libgnutls26:amd64 2.12.23-1ubuntu4.2
zless /usr/share/doc/libgnutls26/changelog.Debian.gz
gnutls26 (2.12.23-1ubuntu4.2) saucy-security; urgency=medium
* SECURITY UPDATE: certificate validation bypass
- debian/patches/CVE-2014-0092.patch: correct return codes in
lib/x509/verify.c.
- CVE-2014-0092
-- Marc Deslauriers Mon, 03 Mar 2014 14:14:00 -0500
EIght years is better than never.
This bug was fixed the same day that it became public knowledge. Unless the bug was discovered by the internal team, this will never be case with closed source.
File under 'M' for 'Manic ranting'
There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).
Huh? Even for SSMTP, certificates can -- and must! -- be checked.
I think you mean ESMTPS. And no, usually TLS certificates are not checked by default (they can be, optionally); many TLS certificates used for ESMTPS are not signed by a CA, so there's nothing to check them against. There's also a new DANE protocol where domains that are using DNSSEC can specify TLS certificate details for mail in the DNS record for the domain, but this is currently not popular (supposedly only about 20 domains are using it). Other issues with this are that a number of DNS servers haven't implemented DNSSEC, and a number of MTAs haven't implemented the DANE protocol either.
And we don't want the situation where mail domains have to have thier TLS certificate signed by a CA, because that gets back into the mess of "which CAs are trustworthy" for mail purposes, paying fees for SSL certificate signatures, and so on. It's better to at least have encrypted email transfers than to only allow encrypted transfers from authenticated senders.
Ok, the major "workstation" & server distro's patched. How about the embedded distro's? OpenWRT? DD-WRT? Do you run OpenVPN on your router? Does it even depend on GNUtls?
How about the hundreds of other embedded distro's? Bank ATMs?
It's better to at least have encrypted email transfers than to only allow encrypted transfers from authenticated senders.
Better in what sense? Without authentication MITM attacks are trivial, making the encryption irrelevant.
If what you say is true (and it probably is) then the state of e-mail security is even worse than I thought it was. Most mail providers don't support TLS anyway, but without authentication it doesn't really matter if they do.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
"Linux" refers to whatever people want it to refer to. Language is decided by the majority and you're the minority, meaning you're using it incorrectly.
Who said anything about aliens? The reptilians are actually an earlier sentient species of Earthling, driven underground by the asteroid impact that ushered in the extinction of the dinosaurs. They're only meddling in primitive Human politics to keep us from interfering with their space program.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.
And thanks to the LGPL license of GnuTLS, all the users have the possibility to upgrade their systems, independently of whether Red Hat, Debian, Ubuntu, Apple, Microsoft believe that maintaining those systems is still commercially convenient or not. GPLv3 would be better, as it would give the users the warranty of being able to actually install the updated code into their devices, which is important for non-PCs.
For all the speed with which Debian rolled out a patch, it'll still be months or years before this patch makes it into the wild on all the systems it's being used on.
When you show me the OS that has a patch for idiot, lazy or incompetent operators, I will buy you a beer.
Forget openwrt... How about all the ISP provided "Firewalls" that are total garbage, have one password, and can not be updated?
Looks like someone can't tell the difference between "March" and "April". Hint: "April" is the one that starts with an "A".
The major distros posted patches for this flaw to their repositories within a day or two of it being made public. (Not to say that it isn't embarrassing for stuff like this to make it into the codebase; but at least it was fixed quickly once it was discovered.)
The GnuTLS bug is freakishly easy to exploit. The OpenSSL bug at least requires you to modify your code to exploit the bug. This one is almost work-free.
If the same bug appears on OpenSSL, I would immediately disable all SSL related applications.
Thank god nothing uses GnuTLS...except aptitude.
(I am a security researcher who spent a day or 2 researching these 2 bugs)
The irony, of course, is that most people haven't read Microsoft's EULA which effectively says 'Not only are we not responsible if Windows fails, but we'll sue you if you try to fix it yourself.'
This is really gonna bite the hundreds of millions running XP who will be orphaned this year when Microsoft stops supporting it. Not only do they face the prospect, in a matter of weeks, of never again seeing security updates from Microsoft, but it will be illegal to even try to fix future bugs themselves (or hire a third party to do it).
This last bit is something that Linux users have as a right
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
MITM requires active interception to eavsdrop, wheras an unencrypted connection is vulnerable to passive eavesdropping. That is the sense in which an encrypted but not properly authenticated connection is "better". Also if the ID of the offered certificate is logged it is possible to audit for a MITM attack after the fact. According to Snowden, the NSA can crack 1024 bit certs' private keys. So really even properly verifying the cert is not secure depending on who your adversary is.
If what you say is true (and it probably is) then the state of e-mail security is even worse than I thought it was. Most mail providers don't support TLS anyway, but without authentication it doesn't really matter if they do.
Actually it's quite common for email providers to support TLS transfers today. And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.
If you look at the mail headers for email you receive, you're likely to find "smtps" or "esmtps" in the Received: lines which indicates that it was sent via a TLS transfer. Most mailing list traffic is often done without TLS, though there are exceptions -- Debian's mailing lists still use TLS transfers, which is good.
Generally you're right to point to router security, but I don't think it's relevant here. Router software package installation -- where you might think you want tls to fetch the package safely -- should be using package signatures rather than relying on tls.
Article writer Dan Goodin missed this point in his first draft. He thought he had a story, and failed at the fact-checking stage.
Would you rely on X.509 for a vpn? The implementation is irrelevant.
ATMs, no. Web banking really does have a problem, and it's much bigger than bugs in tls.
I think David Jao and others are right, and this is not news.
This bug was fixed the same day that it became public knowledge.
What do you mean "public knowledge"? The code was always there, the bug was always "public knowledge". I think what you really mean is "responsibly disclosed" which also happens regularly in closed-source software.
The code was always public knowledge.. the bug itself was still unknown until its discovery last month. With closed source, the only way to find a bug is by seeing it happen in a live running instance, while with open source bugs can also be discovered by individuals through inspection of the code itself.
Also, with open source, a programmer or programming team can effect the necessary fixes themselves if they are unsatisfied with the speed of the software development team, while with closed source, absolutely everyone must wait for the software's dev team to address the issue.
File under 'M' for 'Manic ranting'
The code was always public knowledge.. the bug itself was still unknown until its discovery last month.
Unknown to who? Everybody? You really think responsible disclosure is unique to closed source software? It isn't.
Also, with open source, a programmer or programming team can effect the necessary fixes themselves if they are unsatisfied with the speed of the software development team, while with closed source, absolutely everyone must wait for the software's dev team to address the issue.
Yeah nobody disputed that, you're getting confused.
MITM requires active interception to eavsdrop
It's not like it's impossible to have toolkits for making active interception nearly trivial to do (provided you've got the hardware to run it on) and if you're thinking about ISPs or governments as the attackers, they've got access to the sorts of hardware which can run active interception on a massive scale.
Your main defence against them is that your life is very boring and ordinary and they don't give a shit about you. It's the other major group of attackers — plain old criminals who want to steal your money or your identity — who you're really protecting against.
"Little does he know, but there is no 'I' in 'Idiot'!"
GnuPG implements RFC4880. See also the OpenPGP alliance. GnuTLS implements SSL, TLS and DTLS. See also OpenSSL and PolarSSL.
Your userland software may or may not link against GnuTLS. It's probably more likely to link against OpenSSL.
It's important to understand the mechanisms involved with software that provides facilities for securing information both locally and in transit to others. It's nearly as important to do a bit of research on said mechanisms before engaging in discussions on them.
Write failed: Broken pipe
When they're not entering into eeeeebil same-sex relationships with their deceptively mousey ninja-housemaid hybrids...
The ones that were fixed by the updates for all RHEL-derived distros, like CentOS, a month ago?
mark
Wow who submitted this? This is over a month old and was already on slashdot when it was breaking. Everyone should be patched by now.
And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.
I think you're arguing that would be a bad thing, but in reality it'd be a nearly-irrelevant thing. Without authentication, encryption protects only against the most casual of snoopers, most of whom wouldn't be able to sniff the packets anyway.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
MITM requires active interception to eavsdrop, wheras an unencrypted connection is vulnerable to passive eavesdropping.
Yes, of course. However, in practice the set of real-world circumstances in which an attacker manages to get sufficient physical access to eavesdrop without also getting sufficient physical access to perform active attacks are vanishingly small, at least in the wired networking space. For wireless it's different, of course (assuming there's no link-layer encryption applied), but inter-MTA transfers are almost never wireless.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.
I think you're arguing that would be a bad thing, but in reality it'd be a nearly-irrelevant thing.
No. The word "reality" doesn't apply here, because what you're describing isn't what's being actually done for SMTP.
Without authentication, encryption protects only against the most casual of snoopers, most of whom wouldn't be able to sniff the packets anyway.
No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.
No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.
MITM attack.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.
MITM attack.
That's not a specific example related to TLS or encryption, it's a vague attack classification. The reason I'm asking the question is to find out if there is an actual issue, and so a vague answer like this cannot help our understanding any.
Oh well. OpenSSL apparently has a vulnerability too. sigh :-/
I feel like I'm spelling out the obvious, but: mail server A opens a TLS connection to mail server B to transfer mail, which starts with a TLS handshake, requiring B to send its public key A. The attacker intercepts the message and sends his public key to A, and completes the handshake with both sides, then proceeds to happily pass the data through reading all of it, since he has the session keys on both sides.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I feel like I'm spelling out the obvious, but: mail server A opens a TLS connection to mail server B to transfer mail, which starts with a TLS handshake, requiring B to send its public key A. The attacker intercepts the message and sends his public key to A, and completes the handshake with both sides, then proceeds to happily pass the data through reading all of it, since he has the session keys on both sides.
You've skipped over the PFS key exchange portion used in TLS.
https://en.wikipedia.org/wiki/...
https://en.wikipedia.org/wiki/...
https://en.wikipedia.org/wiki/...
Maybe the MITM exploit you're talking about is possible, I don't know.
It is. There are many tools out there that implement it. It's the whole reason that we use CAs -- not that they're an ideal solution to the problem, but without some way to verify the authenticity of the public key you're using to bootstrap the key exchange, any PK-based key agreement protocol is subject to MITM attacks.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
It is. There are many tools out there that implement it. It's the whole reason that we use CAs -- not that they're an ideal solution to the problem, but without some way to verify the authenticity of the public key you're using to bootstrap the key exchange, any PK-based key agreement protocol is subject to MITM attacks.
MITM can be an issue. More detailed information about the state of things at the link below.
https://wiki.exim.org/lurker/m...