21 ms·

Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping

515 points by Morgawr 13y ago

bananas 13y ago
Thou who reimplements code is doomed to reimplement bugs as well.
zabcik 13y ago
Archlinux pushed the upgrade just 9 hours after the bug was fixed. Damn I love this OS.
- keithpeter 13y ago
  root@teacup:/home/keith# apt-get upgrade The following packages will be upgraded: libgnutls26 Not quite 9 hours but fairly quick on gNewSense 3 as well, no doubt pushed through from Debian Squeeze.
tptacek 13y ago
The vulnerability means that there is an ASN.1 certificate format you can use that will validate against any unpatched GnuTLS-using application, regardless of how you configure ciphersuites and negotiation. The bug isn't cryptographic. It's much simpler and more basic than that. My guess is that it's also been embedded in GnuTLS for longer than the SecureTransport bug had been. For connoisseurs of bogus conspiracy theories, it's worth noting that the coding flaw that produced the bug is much more subtle than "goto fail", but the bug is equally simplistic. Where "goto fail" required a duplicate line, GnuTLS required only a single switched token; not only that, but the bug comes from a mismatch between two common C error checking regimes (a zero-return error and a negative-return error). I think what I like least about the bug is that it was found by the GnuTLS maintainer, long after the code shipped. That's a signal of how much attention GnuTLS gets.
- SimHacker 13y ago
  This is yet another nail in the coffin of Eric Raymond's irresponsible and fallacious "many eyes make all bugs shallow" theory. https://en.wikipedia.org/wiki/Linus's_Law https://en.wikipedia.org/wiki/Linus's_Law Linus's Law as described by Raymond is a claim about software development, named in honor of Linus Torvalds and formulated by Raymond in his essay and book "The Cathedral and the Bazaar" (1999). The law states that "given enough eyeballs, all bugs are shallow"; or more formally: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone." Presenting the code to multiple developers with the purpose of reaching consensus about its acceptance is a simple form of software reviewing. Researchers and practitioners have repeatedly shown the effectiveness of various types of reviewing process in finding bugs and security issues, and also that reviews may be more efficient than testing. In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate. While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".
  - fluidcruft 13y ago
    What evidence is there that there actually were "many eyes" on this code? If anything this underscores the importance of license compatibility in order to maximize the utility of the "many eyes" resource. Honestly, GnuTLS seems to exist purely for ideological shim reasons, and it's not surprising that ideological shim reasons don't motivate "many eyes" to bother show up.
    - tptacek 13y ago
      That's a No True Scotsman argument. The problem with the "many eyes bugs shallow" theory is that all eyes aren't created equally, and the valuable eyes aren't distributed uniformly across all software.
- leoc 13y ago
  > not only that, but the bug comes from a mismatch between two common C error checking regimes (a zero-return error and a negative-return error) So, chalk this up as another triumph for security-critical C?
  - tptacek 13y ago
    Is this an interesting observation? I doubt it a little. What security-conscious developer believes C is a good language in which to write complicated, security-critical code? You write code in C because you have to.
    - deleted 13y ago
      [deleted]
    - leoc 13y ago
      > Is this an interesting observation? Actually people seem to need frequent reminding that we don't live in the best of all possible worlds, and that some of the difficulties in working with the best-available current tools aren't inescapable but rather shortcomings that can and should get fixed sometime. It's great if everyone now knows how suboptimal C-everywhere-forever is on security grounds, at least—but tbh 'security-conscious developer' sounds a little like 'true Scotsman' here. A hae me doots.
    - hyc_symas 13y ago
      Personally I believe C is the best language to develop in. Anything you write in C can be easily used in any other language you care to use; this characteristic is not true for any other language you could name. There is nothing wrong with developing security-critical code in C if you're an experienced C programmer and know what you're doing. The GnuTLS programmers were neither experienced C programmers nor knowledgeable about security; they should not have been writing security-critical code in the first place. And no one should have ever believed that their code was trustworthy.
- TillE 13y ago
  Say what you will about the half dozen mutually incomprehensible error code standards in Win32, at least 0 indicates success in all of them. Well, except for BOOLEAN. I really don't understand why anyone would return an int and have 0 indicate failure. OpenSSL does this too, and it makes no sense to me. I don't know how far this goes back, but clearly we have a long tradition of programs returning 0 to the OS to indicate no error.
  - tptacek 13y ago
    Using zero for errors means you can express error checking directly with C expressions that appear boolean. It's not as safe or rigorous, but is more readable.
    - userbinator 13y ago
      Using nonzero for errors means you can do the same thing. This is common in things like this: if(somefunc()) goto fail; Additionally, if the return is a fail/pass status, there is only one success (0), and you can use all the nonzero values for error codes.
      - prewett 13y ago
        Yes, you can, but that doesn't read very well to my eyes, given most function names. if(open()), if(read()), if (CreateWindowExW()), all suggest success to me. if (!open(...)) goto fail; if (!read(...)) goto fail; if (!close(...)) goto fail; reads a lot nicer to me. Although, the reality is that you need to assign to an error variable, which makes it not as nice and clean.
  - cjensen 13y ago
    No. CreateFile returns INVALID_HANDLE_VALUE which is -1. Compare this to CreateSemaphore which also returns a HANDLE, but returns NULL[1] on failure. Returning int(0) as a failure is often done in C if the return value is a boolean since C lacks a true boolean type. [1] NULL should never be used in actual code because it is ambiguous.
- guelo 13y ago
  It is legitimate to be more concerned about the Apple bug than this bug since the Apple bug affects several orders of magnitudes more people. Conspiracy theorists would postulate that the iPhone is a much more enticing target for the NSA.
  - tptacek 13y ago
    Yes, I agree: that is what conspiracy theorists do regardless of the facts on the ground. But that's tangential to my point. People on HN found the "goto fail" bug damning because of the specific form it took (among other reasons), and I'm happy to point out how damning that form turns out not to be. The fact that GnuTLS is extraordinarily unlikely to host an NSA backdoor helps my point, which is why I brought it up.
  - danso 13y ago
    Note: I am not a conspiracy theorist. However, I would agree with a hypothetical conspiracy theorist who would disagree with your assumption: Linux may be the platform for many high-value targets and companies, so it's not quantity, but..."quality" of a sort.
  - D9u 13y ago
    How many linux based servers are online right now? More than Apple devices? Less?
    - UnoriginalGuy 13y ago
      This doesn't impact every single Linux server online right now, the Apple bug impacted every iOS device which was in use. Orders of magnitude different degrees of harm.
    - deleted 13y ago
      [deleted]
    - uggedal 13y ago
      How many of its programs link to gnutls though? And if I'm not misunderstandig only client software is vulnerable to the cited attack.
- masklinn 13y ago
  > My guess is that it's also been embedded in GnuTLS for longer than the SecureTransport bug had been. One of Ars's commenters linked to http://www.openldap.org/lists/openldap-devel/200802/msg00072.html http://www.openldap.org/lists/openldap-devel/200802/msg00072... edit: acc00 provided a link to the commit introducing the bug: https://www.gitorious.org/gnutls/gnutls/commit/0fba2d908da6d0df821991ea5fdbeeda0f4ff089 https://www.gitorious.org/gnutls/gnutls/commit/0fba2d908da6d... it's a bit more than 10 years old.
  - rquirk 13y ago
    Was the commit that added the problem not this one? It adds the issuer_version and returns it as the value for the check instead of returning 0. https://www.gitorious.org/gnutls/gnutls/commit/12f135e099a570991ace460a83a291a136604c71 https://www.gitorious.org/gnutls/gnutls/commit/12f135e099a57... That was 2003-03-03, 11 years almost to the day.
- kilemensi 13y ago
  Correct me if I'm wrong, but I think most developers were "disappointed" with the "goto fail" because it was code structure issue which could and should have been caught at compile time. Hence the conspiracy theories because Apple should have these tools in place. This one on the other hand, is a logical bug (interpretation of return codes) which is relatively harder to track especially when the use of said return codes is not consistent throughout the project
- bcoates 13y ago
  Is there any auditing technique that could realistically find out, after the fact, how often this long-outstanding bug has been exploited over the years it has been in place, like collecting a sample of presented certificates? If we can't write perfect software, at least being able to quantify the damage would be a good start.
  - e12e 13y ago
    Well, I suppose it might be a good idea for clients in general to log all certificates as they are presented -- the amount of data should be negligible. For a more organized approach there's always: https://www.eff.org/observatory https://www.eff.org/observatory I'm not sure if the data dumps contain the data needed to search for this bug in particular (but I suppose it should)? I wonder if moving most logic from these libraries to lua or guile might be a good idea -- and keep only the bare minimum in C/assembler (as I understand it, the key crypto algorithms need to be in something like C in order to be able to guarantee (as much as possible) against side-channel attacks). But I don't know if there are any real reasons to keep everything else in C (other than possibly that making things easier to port/compile/etc?).
- cperciva 13y ago
  That's a signal of how much attention GnuTLS gets. It's a signal of how much attention the dark and dusty corners of all open source code gets. My "favourite" FreeBSD advisory was the 2011 telnetd "christmas present" -- remote root to any system running telnetd with the default options. The bug was in routines for setting up encrypted telnet sessions... who even knew that telnet had encryption? The bug was a blindingly obvious buffer overflow, but nobody goes digging through telnetd looking for encryption code. About six months after that advisory, I heard from a major aircraft manufacturer that they had been using the BSD telnetd code to provide a channel for in-flight tuning of engine performance. This is why I award bug bounties for punctuation errors in comments in the Tarsnap source code -- it encourages people to read all the code, not just the interesting bits.
  - sigzero 13y ago
    I believe the bug was actually reported but not fixed: http://www.openldap.org/lists/openldap-devel/200802/msg00072.html http://www.openldap.org/lists/openldap-devel/200802/msg00072...
    - tokenrove 13y ago
      All of Howard Chu's analysis in that thread is great, but he didn't discover or report this bug. Reading that message should make it clear; he's talking about sloppy string handling and bad APIs, neither of which has anything to do with this bug, which was mixed-up return code semantics in an internal, static function. Look later in that thread for some other pretty sloppy code he tears apart, though.
      - hyc_symas 13y ago
        The point is that the GnuTLS code quality was obviously crap, the developers were obviously incompetent, and only a fool would trust GnuTLS with their system security. I pointed out numerous problems - more in private emails to the GnuTLS authors and Debian maintainers, not just those published on the list - all related to the sloppy programming practices and inconsistent APIs. This mixed-up return code semantics is just another consequence of those sloppy programming practices. How many ways do you have to see that "this software sucks and the developers don't know WTF they're doing" before you realize you shouldn't be trusting them?
- deleted 13y ago
  [deleted]
computer 13y ago
Are all programs dynamically linked with GnuTLS, or are there packages that have to be recompiled separately? (On Debian/Arch)
- jvreeland 13y ago
  I can't speak for absolutely every package but most if not all on Arch will be dynamically linked and shouldn't need to be recompiled. (The new version was released on Arch 3/3)
pera 13y ago
Linux? afaik I don't use any program that requires GnuTLS...
- keithpeter 13y ago
  I use TLS encrypted connections when fetching and sending e-mail (I use Evolution with a pop mail connection and a roving SMTP for sending).
- nandhp 13y ago
  Are you sure? At least on Debian, GnuTLS is used by CUPS, exim4, cURL/GnuTLS, GnomeVFS, Gtk, NetworkManager, libvncclient, libvncserver, VLC, and wget.
  - scott_karana 13y ago
    Git and bloody GnuPG are also on that list.
    - pera 13y ago
      Oh.. well, it seems that Debian uses GnuTLS instead of OpenSSL, I was not aware of that. In Arch Linux very few packages depends on GnuTlS.
  - e12e 13y ago
    "flashplugin-nonfree Depends libcurl3-gnutls"
- pbhjpbhj 13y ago
  Aptitude tells me there are 179 packages dependent on libgnutls26 - about 20 are installed including: chromium-browser, cups-daemon, libldap, librtmp, libvncserver0, libwireshark3, telepathy (KDE), vlc-nox. The only thing I really know I use TLS for is email server connections via Thunderbird however.
  - makomk 13y ago
    I think off-hand both Thunderbird and Chromium use NSS for their TLS support.
Geee 13y ago
Is it that they just now started actually testing these implementations, for the first time? Even if you wouldn't follow TDD practices, it's obvious that anything that implements a protocol of some sort (particularly a security protocol), should be tested to actually follow that protocol. Isn't that common sense? What is going on?
- tptacek 13y ago
  TLS stacks aren't built with TDD practices for the same reason that the kernel TCP/IP stack isn't built with TDD: the things that go wrong in TLS involve the state machines of a distributed protocol and somewhat elaborate mathematical operations. Read Schneier and Ferguson describing in _Cryptographic Engineering_ the steps required to validate a bignum arithmetic library. That's one of the smaller problems in getting a TLS stack right, and it's complicated. If you demand that your browser implement protocols the same way ActiveRecord implements SQL join generation, you should just stop using browsers; none of them are built the way you'd want them to be. I have a hard time not being dismissive about TDD's role in improving systems software security. If you're going to propose a radical change in the way systems code is written (or, worse, hold systems developers to a nonexistent standard), be intellectually coherent about it: demand that security-critical code be implemented in a rigorous language, like idiomatic Haskell. Don't propose monumental changes that promise only that the resulting code will be asymptotically secure as Ruby on Rails.
  - jsmthrowaway 13y ago
    That's not what he said at all and your comment dips into "the elite few know more than you do" territory, particularly with the unnecessary dig at Web development. His only mention of TDD was "even if you don't," yet you jumped on the acronym TDD and took him to task for it. What I read him as saying (and agree with) is that he's surprised that GnuTLS isn't tested against known-bad certificates in a simple integration test that doesn't require a Ph.D. to set up, as you imply.
    - tptacek 13y ago
      What "known-bad" certificate? You appear to be suffering from hindsight bias. We know what the bad certs look like now, but they're idiosyncratically related to a very, very specific bug: having the test case that checks for this bug implies that you don't have the bug to begin with. The fallacy that you could have easily written a test case for this bug appears neatly encapsulates the weakness of "TDD" as a mitigation for programming flaws.
kenferry 13y ago
Patch fixing the bug: https://www.gitorious.org/gnutls/gnutls/commit/855127da290a280df839038671ae6aba01957736 https://www.gitorious.org/gnutls/gnutls/commit/855127da290a2... Basically, the code said bool isOk() { result = someCheckReturningNegativeOnFailure() if (result < 0) goto cleanup; cleanup: ... return result; } The issue is that failure is communicated with a negative number in one case and 0 in another, and the wires got crossed.
- QSIITurbo 13y ago
  Yeah. While they're at it, why not change every function to return "int". Then just cast to proper type at usage. /s (And no, bool is not the proper way to go either.) But seriously, I'm amazed that code this critical uses sloppy typing. I mean, they might as well use Python ffs. Maybe it's historical burden?
droprip 13y ago
I am not very familiar with low level C or the coding patterns used with it, so I must ask; why do we see goto statements in both of these recent bugs? As far as I know it's a bad practice overall, is there some specific reason for using it here?
- sp332 13y ago
  Goto is an acceptable and idiomatic way to implement error handling. If something goes wrong in an inner loop, you can just break out of all the loops and go to the failure state. e.g. https://stackoverflow.com/questions/788903/valid-use-of-goto-for-error-management-in-c https://stackoverflow.com/questions/788903/valid-use-of-goto...
- nhaehnle 13y ago
  Since C has neither garbage collection nor the RAII pattern of C++, it is very common for C functions to have a cleanup section at the end, where allocated memory and other resources are freed again. In many C projects (including the Linux kernel) it is a common and accepted pattern to jump into the right position of the cleanup sequence using a goto.
- wolf550e 13y ago
  The correct way to do error handling in C is using goto statements. Dijkstra did not mean local goto statements. He meant something you will not find in any C code you are likely to use on a rhel/debian machine.
- josteink 13y ago
  Apart from the other reasons mentioned here, it probably translates to compact code which fits well within level-1 instruction cache in modern CPU when translated into assembly, without any need for additional lexical scopes and stack allocations.
- EddSeabrook 13y ago
  C doesn't have exceptions, so goto is commonly used to emulate that style of programming.
flurpitude 13y ago
Coming so soon after the Apple bug, it does make one wonder whether some or all of these are deliberate backdoors. Relevant musings by Bruce Schneier: https://www.schneier.com/blog/archives/2014/02/was_the_ios_ssl.html https://www.schneier.com/blog/archives/2014/02/was_the_ios_s...
- weavejester 13y ago
  Why would coming soon after the Apple bug make it more likely this bug was deliberate?
- rmc 13y ago
  Or the attention is now on "does your SSL cert handlying code have any shortcuts? Let's everyone double and triple check"
- ksk 13y ago
  Two heads in a row.. the coin must be rigged ;)
josteink 13y ago
Just checked my Ubuntu boxes. Update has been pushed and is ready to apt-get.
- shavenwarthog2 13y ago
  Yes. For others: 1) consider installing the "unattended-upgrades" tool, to install security updates via cron. https://help.ubuntu.com/community/AutomaticSecurityUpdates https://help.ubuntu.com/community/AutomaticSecurityUpdates 2) specific Ubuntu Security Notice on GnuTLS: http://www.ubuntu.com/usn/usn-2121-1/ http://www.ubuntu.com/usn/usn-2121-1/ 3) List specific package affected: dpkg-query -W libgnutls* libgnutls-openssl27:amd64 2.12.23-1ubuntu4 libgnutls26:amd64 2.12.23-1ubuntu4 I'm on Linux Mint, and the above seem to show that I'm protected. Yay!
  - wreegab 13y ago
    For Saucy, the fix is in: .../ubuntu/+source/gnutls26/2.12.23-1ubuntu4.2 Yours is: .../ubuntu/+source/gnutls26/2.12.23-1ubuntu4 See: https://launchpad.net/ubuntu/+source/gnutls26/2.12.23-1ubuntu4.2">https://launchpad.net/ubuntu/+source/gnutls26/2.12.23-1ubuntu4.2 https://launchpad.net/ubuntu/+source/gnutls26/2.12.23-1ubunt...
- deleted 13y ago
  [deleted]
- deleted 13y ago
  [deleted]
vezzy-fnord 13y ago
Makes me wonder how long this may have been used as a 0-day.
bbanyc 13y ago
So which projects actually use GnuTLS as opposed to OpenSSL (Apache, lighttpd, nginx) or NSS (Firefox, Chrome)? I'm aware of Debian linking some packages against GnuTLS to avoid the supposed GPL incompatibility issue with OpenSSL, but the only thing I've seen that explicitly uses GnuTLS is Emacs 24.
- aroch 13y ago
  Apache can (and maybe should) use gnuTLS
  - josh-wrale 13y ago
    Please expound on why you believe Apache 'maybe should' use gnuTLS.
    - aroch 13y ago
      Back when I still used Apache it didn't have support for TLS 1.1/1.2 due to the dep on OpenSSL and thus none of the better FS ciphers. So compiling against gnuTLS allowed for those. That's now been rectified.
acc00 13y ago
Commit introducing the bug: https://www.gitorious.org/gnutls/gnutls/commit/0fba2d908da6d0df821991ea5fdbeeda0f4ff089 https://www.gitorious.org/gnutls/gnutls/commit/0fba2d908da6d...
- zwily 13y ago
  And the fix: https://www.gitorious.org/gnutls/gnutls/commit/6aa26f78150ccbdf0aec1878a41c17c41d358a3b?diffmode=sidebyside#lib/x509/verify.c https://www.gitorious.org/gnutls/gnutls/commit/6aa26f78150cc...
- acqq 13y ago
  Commit: #0fba2d9 "Improved the certificate generation stuff."
  - snarfy 13y ago
    On one hand this makes me wary of the quality of GnuTLS source in general, and on the other I know I am guilty of similar commit messages.
- elwell 13y ago
  wow "10 years ago" and git was only released 9 years ago
  - Jach 13y ago
    Your comment made me pause while reading this thread -- what exactly is surprising about that? Repo migration is a thing...
- Estragon 13y ago
  Maybe the patch wouldr have gotten more attention if he'd broken it up into smaller chunks.
JshWright 13y ago
Disclaimer: My understanding of the goto fail bug is based on agl's writeup, and my understanding of the GnuTLS bug is limited to this article. In both of these cases, it seems the code starts with the assumption that the cert is valid and then tries to find various conditions to invalidate it. Isn't that backwards? Why not start with an assumption that the cert is untrusted until you've proven otherwise?
- pg_is_a_butt 13y ago
  because AMURIKUH
- tptacek 13y ago
  That's not what happened here. The problem is that the logic of the validation predicate was broken. In fact, this bug happened after the code had determined the cert was invalid; it just signaled the error improperly.
- guscost 13y ago
  This is an interesting question. I agree that invalid-by-default makes sense when reasoning about the higher-level system, but regarding the actual Boolean logic it seems that if a critical condition is broken the particular formulation will not make much of a difference. Additionally, it seems that in certain situations having several plain-if conditionals set the valid state to `1` would be less robust than having several conditionals set it to `0`. In the first case if any one of the conditions have bugs the false valid state can happen, whereas in the second case the last conditional to execute would have to contain the bug. Can anyone else comment on this? Are there relevant theories and/or best practices which have been discussed in the security community?
  - JshWright 13y ago
    What about several conditionals that set various elements of a struct to 1, and the cert is valid iff all elements are 1. At least that way a skipped check (i.e. goto fail;) wouldn't result in a false positive...
HallOfQuotes 13y ago
For to be free is not merely to cast off one's chains, but to live in a way that respects and enhances the freedom of others. Read more at http://www.hallofquotes.com/quote/18608.html#OiEf9RybEMiL0J0w.99 http://www.hallofquotes.com/quote/18608.html#OiEf9RybEMiL0J0...
afhsfsfdsss88 13y ago
Can we all finally accept the fact that what is most needed now is not a new whizbang but a comprehensive review of all of the core pieces of software that we depend on as a base for making new whizbangs? How many critical and ancient bugs still remain undiscovered? Everyday there is a new Telegram, Cryptocat, etc. all presumably being constructed on top of insecure libraries. What progress can we make with such shaky foundations? There has been word that the Linux kernel devs are considering slowing new feature adoption for a time while focusing on bug discovery and elimination. PLEASE, EVERYONE ELSE CONSIDER DOING THE SAME.
- newman314 13y ago
  At a minimum, commonly used security packages should be reviewed and OS distribution maintainers commit to updating to latest versions of said packages regardless of the age of the OS. For example, Ubuntu 12.04 LTS uses an older version of OpenSSH and OpenSSL. There should be no reason why Ubuntu (and others) can't commit to updating to the latest versions so that features in say OpenSSH 6.5p1 are avail. BTW, saying that you can compile and install this yourself is noted beforehand but honestly, how many people do that on a regular basis? What I'm getting at is that security software can and should be held to a higher and current standard precisely because it affects so many other pieces of software in fundamental ways. It's not a big deal if the latest version of bc is not installed but it sure is if GnuTLS or OpenSSL is broken.
0xdeadbeefbabe 13y ago
What's with the back button ARS? Helping me stay off hn?
thrownaway2424 13y ago
Demand unit tests and comments. I mean, I was incensed by the quality of the Apple code, but this code is just as bad: * Checks if the issuer of a certificate is a * Certificate Authority, or if the certificate is the same * as the issuer (and therefore it doesn't need to be a CA). * * Returns true or false, if the issuer is a CA, * or not. */ static int check_if_ca (gnutls_x509_crt_t cert, gnutls_x509_crt_t issuer, unsigned int flags) { Sure, returns "true" or "false" which are not things in C. This actually returns either 0 or 1. Many C library functions return 0 for OK and non-zero for error. This one returns 0 for error and 1 for OK. Imagine you are reviewing the a call site of this code: if (check_if_ca(...)) { // CA is valid, proceed } vs. if (check_if_ca(...) == 0) { // CA is valid, proceed } To the reviewer who is accustomed to strcmp, either of these might appear to be fine, meaning that the reviewer (or even the author) has to carefully check the documentation of this function. What else is wrong with this signature? For one thing it would be easy to swap the arguments around: if (check_if_ca(cert, issuer, flags)) ... if (check_if_ca(issuer, cert, flags)) ... What's the difference? They both look reasonable. What are the valid/relevant values of |flags|? Would it be easier to comprehend |flags| if it were an options struct, e.g. GNUTLSCertificateVerificationOptions opts; opts.set_allow_rsa_md2(true); ... cert.Verify(opts); ? Would it be easier to verify the correctness of a call site of check_if_ca if it looked like this: if (issuer_cert.IsCA() || cert == issuer_cert) ... Where are the unit tests. The unit tests should be right here in the lib directory as whatever_unittest.c, adjacent to the source file they are testing, so you don't have to go groping around in the tree trying to find the relevant test, if it even exists. By the way, I found no test that calls this function. Basically this code has all the same problems as the Apple code, except for the mixed tabs/spaces stuff (as far as I can tell). It would be shameful for any professional programmer or organization of programmers to create this code.
- sillysaurus3 13y ago
  What's necessary is to get at least two experienced cryptographers thinking about every piece of security-critical code, because that's what will prevent bugs. It's also why security audits are so expensive: they work. The code absolutely should have had clearer comments, since if every step were commented then some of the return value confusion may have been avoided. The style of the code itself probably isn't as terrible as it seems at first glance, though. It's also not easy to write useful unit tests for a security stack.
deleted 13y ago
[deleted]
stonogo 13y ago
This is not a bug that leaves "linux" open to anything. It's a GnuTLS bug, and you should be using openssl anyway.
- murftown 13y ago
  This
- michh 13y ago
  Why should I be using OpenSSL other than this bug?
  - stonogo 13y ago
    GnuTLS exists as a project almost exclusively due to ideology concerns -- people who prefer GPL do not like OpenSSL's license. That's not to say that technically-capable people are not behind it, but there are not as many as involved with OpenSSL. There are very few technical advantages to GnuTLS, and almost all of them have been transient (as in, certain protocols and ciphers have been supported in GnuTLS before other libraries). I do not have the time to go over why other libraries occasionally lag behind GnuTLS, but I can specify, for instance, that OpenSSL code goes through a more thorough and lengthy review process before it gets 'shipped' (inasmuch as that term applies to not-for-profit software). Code that supports GnuTLS can easily be made to support OpenSSL (or several other such libraries). It really is a matter of which license you prefer, and licensing should never be a consideration in security.
- nzp 13y ago
  While I agree with most of these two sentences, you can't really be sure there's no such bug in OpenSSL. I mean, not this specific bug, but a similar hard-to-imagine-random-situation bug.
rdl 13y ago
SSL fuzzing seems like it could be a really profitable area of research. I wonder why there aren't better conformance testing tools for SSL (other than SSL being kind of hideously baroque).
hiphopyo 13y ago
Choose OpenBSD for your Unix needs. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant firewall PF, and the world's most elegant mail server OpenSMTPD. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.
- gonzo 13y ago
  unfortunately, it is as performant as a pig in winter mud.
benihana 13y ago
So I guess the whole meme of "if the code was open to scrutiny, this bug wouldn't have happened" doesn't seem to be so valid now. There was legitimate outrage on Hacker News that Apple could allow such a bug, and that it was an indicator of the evil of closed source systems.
mattjaynes 13y ago
Does anyone know if this affects any of the popular configuration management tools like Puppet, Chef, SaltStack, etc?
- vacri 13y ago
  If you're on a Debian derivative, you can find out which installed packages depend on an item with "aptitude why [foo]"
laumars 13y ago
As someone who uses tends to compile most things against openssl, I was wondering if someone could answer how widespread gnutls usage is?
ufmace 13y ago
Does this make anyone else's conspiracy antenna twitch a bit? The Apple one was only a little suspicious in that way. A bug in another major crypto library that weakens it in a very similar way makes it look a little more suspicious. Since this is OSS, the investigation of the source control logs will probably be a bit more public. I wonder if they'll find anything interesting.
hoers 13y ago
Is there a list somewhere of which applications use GnuTLS?
niio 13y ago
albertop 13y ago
So I wonder where are all commenters blasting Apple for careless coding. Crypto is brittle.
murftown 13y ago
How many apps really use GnuTLS anyways? Apache doesn't by default. SSH doesn't. Are most RedHat installations therefore not really affected?
balls187 13y ago
Windows is bound to be next. #it_comes_in_threes
elwell 13y ago
But I thought open-source is immune to slip-ups like this? /s
greatsuccess 13y ago
After Apple and now GNU, henceforth no SSL distribution should be accepted at face value without proof of continuous automated testing results. Period. This is a scandal now.
deleted 13y ago
[deleted]
arunc 13y ago
That's a good hype for GnuTLS, but most of the packages that I know of uses OpenSSL - Apache, Nginx and so on. So it doesn't really matter.
ybaumes 13y ago
Since 2005? 10 years long in production? And while the code is open, no-one ever seen the bug? Is that the power of open source??
joelthelion 13y ago
Is there a tool to check if you're affected?

515 points by Morgawr 13y ago

bananas 13y ago

Thou who reimplements code is doomed to reimplement bugs as well.

zabcik 13y ago

Archlinux pushed the upgrade just 9 hours after the bug was fixed. Damn I love this OS.

keithpeter 13y ago
root@teacup:/home/keith# apt-get upgrade The following packages will be upgraded: libgnutls26 Not quite 9 hours but fairly quick on gNewSense 3 as well, no doubt pushed through from Debian Squeeze.

tptacek 13y ago

The vulnerability means that there is an ASN.1 certificate format you can use that will validate against any unpatched GnuTLS-using application, regardless of how you configure ciphersuites and negotiation. The bug isn't cryptographic. It's much simpler and more basic than that. My guess is that it's also been embedded in GnuTLS for longer than the SecureTransport bug had been. For connoisseurs of bogus conspiracy theories, it's worth noting that the coding flaw that produced the bug is much more subtle than "goto fail", but the bug is equally simplistic. Where "goto fail" required a duplicate line, GnuTLS required only a single switched token; not only that, but the bug comes from a mismatch between two common C error checking regimes (a zero-return error and a negative-return error). I think what I like least about the bug is that it was found by the GnuTLS maintainer, long after the code shipped. That's a signal of how much attention GnuTLS gets.

SimHacker 13y ago
This is yet another nail in the coffin of Eric Raymond's irresponsible and fallacious "many eyes make all bugs shallow" theory. https://en.wikipedia.org/wiki/Linus's_Law https://en.wikipedia.org/wiki/Linus's_Law Linus's Law as described by Raymond is a claim about software development, named in honor of Linus Torvalds and formulated by Raymond in his essay and book "The Cathedral and the Bazaar" (1999). The law states that "given enough eyeballs, all bugs are shallow"; or more formally: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone." Presenting the code to multiple developers with the purpose of reaching consensus about its acceptance is a simple form of software reviewing. Researchers and practitioners have repeatedly shown the effectiveness of various types of reviewing process in finding bugs and security issues, and also that reviews may be more efficient than testing. In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate. While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".
- fluidcruft 13y ago
  What evidence is there that there actually were "many eyes" on this code? If anything this underscores the importance of license compatibility in order to maximize the utility of the "many eyes" resource. Honestly, GnuTLS seems to exist purely for ideological shim reasons, and it's not surprising that ideological shim reasons don't motivate "many eyes" to bother show up.
  - tptacek 13y ago
    That's a No True Scotsman argument. The problem with the "many eyes bugs shallow" theory is that all eyes aren't created equally, and the valuable eyes aren't distributed uniformly across all software.
leoc 13y ago
> not only that, but the bug comes from a mismatch between two common C error checking regimes (a zero-return error and a negative-return error) So, chalk this up as another triumph for security-critical C?
- tptacek 13y ago
  Is this an interesting observation? I doubt it a little. What security-conscious developer believes C is a good language in which to write complicated, security-critical code? You write code in C because you have to.
  - deleted 13y ago
    [deleted]
  - leoc 13y ago
    > Is this an interesting observation? Actually people seem to need frequent reminding that we don't live in the best of all possible worlds, and that some of the difficulties in working with the best-available current tools aren't inescapable but rather shortcomings that can and should get fixed sometime. It's great if everyone now knows how suboptimal C-everywhere-forever is on security grounds, at least—but tbh 'security-conscious developer' sounds a little like 'true Scotsman' here. A hae me doots.
  - hyc_symas 13y ago
    Personally I believe C is the best language to develop in. Anything you write in C can be easily used in any other language you care to use; this characteristic is not true for any other language you could name. There is nothing wrong with developing security-critical code in C if you're an experienced C programmer and know what you're doing. The GnuTLS programmers were neither experienced C programmers nor knowledgeable about security; they should not have been writing security-critical code in the first place. And no one should have ever believed that their code was trustworthy.
TillE 13y ago
Say what you will about the half dozen mutually incomprehensible error code standards in Win32, at least 0 indicates success in all of them. Well, except for BOOLEAN. I really don't understand why anyone would return an int and have 0 indicate failure. OpenSSL does this too, and it makes no sense to me. I don't know how far this goes back, but clearly we have a long tradition of programs returning 0 to the OS to indicate no error.
- tptacek 13y ago
  Using zero for errors means you can express error checking directly with C expressions that appear boolean. It's not as safe or rigorous, but is more readable.
  - userbinator 13y ago
    Using nonzero for errors means you can do the same thing. This is common in things like this: if(somefunc()) goto fail; Additionally, if the return is a fail/pass status, there is only one success (0), and you can use all the nonzero values for error codes.
    - prewett 13y ago
      Yes, you can, but that doesn't read very well to my eyes, given most function names. if(open()), if(read()), if (CreateWindowExW()), all suggest success to me. if (!open(...)) goto fail; if (!read(...)) goto fail; if (!close(...)) goto fail; reads a lot nicer to me. Although, the reality is that you need to assign to an error variable, which makes it not as nice and clean.
- cjensen 13y ago
  No. CreateFile returns INVALID_HANDLE_VALUE which is -1. Compare this to CreateSemaphore which also returns a HANDLE, but returns NULL[1] on failure. Returning int(0) as a failure is often done in C if the return value is a boolean since C lacks a true boolean type. [1] NULL should never be used in actual code because it is ambiguous.
guelo 13y ago
It is legitimate to be more concerned about the Apple bug than this bug since the Apple bug affects several orders of magnitudes more people. Conspiracy theorists would postulate that the iPhone is a much more enticing target for the NSA.
- tptacek 13y ago
  Yes, I agree: that is what conspiracy theorists do regardless of the facts on the ground. But that's tangential to my point. People on HN found the "goto fail" bug damning because of the specific form it took (among other reasons), and I'm happy to point out how damning that form turns out not to be. The fact that GnuTLS is extraordinarily unlikely to host an NSA backdoor helps my point, which is why I brought it up.
- danso 13y ago
  Note: I am not a conspiracy theorist. However, I would agree with a hypothetical conspiracy theorist who would disagree with your assumption: Linux may be the platform for many high-value targets and companies, so it's not quantity, but..."quality" of a sort.
- D9u 13y ago
  How many linux based servers are online right now? More than Apple devices? Less?
  - UnoriginalGuy 13y ago
    This doesn't impact every single Linux server online right now, the Apple bug impacted every iOS device which was in use. Orders of magnitude different degrees of harm.
  - deleted 13y ago
    [deleted]
  - uggedal 13y ago
    How many of its programs link to gnutls though? And if I'm not misunderstandig only client software is vulnerable to the cited attack.
masklinn 13y ago
> My guess is that it's also been embedded in GnuTLS for longer than the SecureTransport bug had been. One of Ars's commenters linked to http://www.openldap.org/lists/openldap-devel/200802/msg00072.html http://www.openldap.org/lists/openldap-devel/200802/msg00072... edit: acc00 provided a link to the commit introducing the bug: https://www.gitorious.org/gnutls/gnutls/commit/0fba2d908da6d0df821991ea5fdbeeda0f4ff089 https://www.gitorious.org/gnutls/gnutls/commit/0fba2d908da6d... it's a bit more than 10 years old.
- rquirk 13y ago
  Was the commit that added the problem not this one? It adds the issuer_version and returns it as the value for the check instead of returning 0. https://www.gitorious.org/gnutls/gnutls/commit/12f135e099a570991ace460a83a291a136604c71 https://www.gitorious.org/gnutls/gnutls/commit/12f135e099a57... That was 2003-03-03, 11 years almost to the day.
kilemensi 13y ago
Correct me if I'm wrong, but I think most developers were "disappointed" with the "goto fail" because it was code structure issue which could and should have been caught at compile time. Hence the conspiracy theories because Apple should have these tools in place. This one on the other hand, is a logical bug (interpretation of return codes) which is relatively harder to track especially when the use of said return codes is not consistent throughout the project
bcoates 13y ago
Is there any auditing technique that could realistically find out, after the fact, how often this long-outstanding bug has been exploited over the years it has been in place, like collecting a sample of presented certificates? If we can't write perfect software, at least being able to quantify the damage would be a good start.
- e12e 13y ago
  Well, I suppose it might be a good idea for clients in general to log all certificates as they are presented -- the amount of data should be negligible. For a more organized approach there's always: https://www.eff.org/observatory https://www.eff.org/observatory I'm not sure if the data dumps contain the data needed to search for this bug in particular (but I suppose it should)? I wonder if moving most logic from these libraries to lua or guile might be a good idea -- and keep only the bare minimum in C/assembler (as I understand it, the key crypto algorithms need to be in something like C in order to be able to guarantee (as much as possible) against side-channel attacks). But I don't know if there are any real reasons to keep everything else in C (other than possibly that making things easier to port/compile/etc?).
cperciva 13y ago
That's a signal of how much attention GnuTLS gets. It's a signal of how much attention the dark and dusty corners of all open source code gets. My "favourite" FreeBSD advisory was the 2011 telnetd "christmas present" -- remote root to any system running telnetd with the default options. The bug was in routines for setting up encrypted telnet sessions... who even knew that telnet had encryption? The bug was a blindingly obvious buffer overflow, but nobody goes digging through telnetd looking for encryption code. About six months after that advisory, I heard from a major aircraft manufacturer that they had been using the BSD telnetd code to provide a channel for in-flight tuning of engine performance. This is why I award bug bounties for punctuation errors in comments in the Tarsnap source code -- it encourages people to read all the code, not just the interesting bits.
- sigzero 13y ago
  I believe the bug was actually reported but not fixed: http://www.openldap.org/lists/openldap-devel/200802/msg00072.html http://www.openldap.org/lists/openldap-devel/200802/msg00072...
  - tokenrove 13y ago
    All of Howard Chu's analysis in that thread is great, but he didn't discover or report this bug. Reading that message should make it clear; he's talking about sloppy string handling and bad APIs, neither of which has anything to do with this bug, which was mixed-up return code semantics in an internal, static function. Look later in that thread for some other pretty sloppy code he tears apart, though.
    - hyc_symas 13y ago
      The point is that the GnuTLS code quality was obviously crap, the developers were obviously incompetent, and only a fool would trust GnuTLS with their system security. I pointed out numerous problems - more in private emails to the GnuTLS authors and Debian maintainers, not just those published on the list - all related to the sloppy programming practices and inconsistent APIs. This mixed-up return code semantics is just another consequence of those sloppy programming practices. How many ways do you have to see that "this software sucks and the developers don't know WTF they're doing" before you realize you shouldn't be trusting them?
deleted 13y ago
[deleted]

computer 13y ago

Are all programs dynamically linked with GnuTLS, or are there packages that have to be recompiled separately? (On Debian/Arch)

jvreeland 13y ago
I can't speak for absolutely every package but most if not all on Arch will be dynamically linked and shouldn't need to be recompiled. (The new version was released on Arch 3/3)

pera 13y ago

Linux? afaik I don't use any program that requires GnuTLS...

keithpeter 13y ago
I use TLS encrypted connections when fetching and sending e-mail (I use Evolution with a pop mail connection and a roving SMTP for sending).
nandhp 13y ago
Are you sure? At least on Debian, GnuTLS is used by CUPS, exim4, cURL/GnuTLS, GnomeVFS, Gtk, NetworkManager, libvncclient, libvncserver, VLC, and wget.
- scott_karana 13y ago
  Git and bloody GnuPG are also on that list.
  - pera 13y ago
    Oh.. well, it seems that Debian uses GnuTLS instead of OpenSSL, I was not aware of that. In Arch Linux very few packages depends on GnuTlS.
- e12e 13y ago
  "flashplugin-nonfree Depends libcurl3-gnutls"
pbhjpbhj 13y ago
Aptitude tells me there are 179 packages dependent on libgnutls26 - about 20 are installed including: chromium-browser, cups-daemon, libldap, librtmp, libvncserver0, libwireshark3, telepathy (KDE), vlc-nox. The only thing I really know I use TLS for is email server connections via Thunderbird however.
- makomk 13y ago
  I think off-hand both Thunderbird and Chromium use NSS for their TLS support.

Geee 13y ago

Is it that they just now started actually testing these implementations, for the first time? Even if you wouldn't follow TDD practices, it's obvious that anything that implements a protocol of some sort (particularly a security protocol), should be tested to actually follow that protocol. Isn't that common sense? What is going on?

tptacek 13y ago
TLS stacks aren't built with TDD practices for the same reason that the kernel TCP/IP stack isn't built with TDD: the things that go wrong in TLS involve the state machines of a distributed protocol and somewhat elaborate mathematical operations. Read Schneier and Ferguson describing in _Cryptographic Engineering_ the steps required to validate a bignum arithmetic library. That's one of the smaller problems in getting a TLS stack right, and it's complicated. If you demand that your browser implement protocols the same way ActiveRecord implements SQL join generation, you should just stop using browsers; none of them are built the way you'd want them to be. I have a hard time not being dismissive about TDD's role in improving systems software security. If you're going to propose a radical change in the way systems code is written (or, worse, hold systems developers to a nonexistent standard), be intellectually coherent about it: demand that security-critical code be implemented in a rigorous language, like idiomatic Haskell. Don't propose monumental changes that promise only that the resulting code will be asymptotically secure as Ruby on Rails.
- jsmthrowaway 13y ago
  That's not what he said at all and your comment dips into "the elite few know more than you do" territory, particularly with the unnecessary dig at Web development. His only mention of TDD was "even if you don't," yet you jumped on the acronym TDD and took him to task for it. What I read him as saying (and agree with) is that he's surprised that GnuTLS isn't tested against known-bad certificates in a simple integration test that doesn't require a Ph.D. to set up, as you imply.
  - tptacek 13y ago
    What "known-bad" certificate? You appear to be suffering from hindsight bias. We know what the bad certs look like now, but they're idiosyncratically related to a very, very specific bug: having the test case that checks for this bug implies that you don't have the bug to begin with. The fallacy that you could have easily written a test case for this bug appears neatly encapsulates the weakness of "TDD" as a mitigation for programming flaws.

kenferry 13y ago

Patch fixing the bug: https://www.gitorious.org/gnutls/gnutls/commit/855127da290a280df839038671ae6aba01957736 https://www.gitorious.org/gnutls/gnutls/commit/855127da290a2... Basically, the code said bool isOk() { result = someCheckReturningNegativeOnFailure() if (result < 0) goto cleanup; cleanup: ... return result; } The issue is that failure is communicated with a negative number in one case and 0 in another, and the wires got crossed.

QSIITurbo 13y ago
Yeah. While they're at it, why not change every function to return "int". Then just cast to proper type at usage. /s (And no, bool is not the proper way to go either.) But seriously, I'm amazed that code this critical uses sloppy typing. I mean, they might as well use Python ffs. Maybe it's historical burden?

droprip 13y ago

I am not very familiar with low level C or the coding patterns used with it, so I must ask; why do we see goto statements in both of these recent bugs? As far as I know it's a bad practice overall, is there some specific reason for using it here?

sp332 13y ago
Goto is an acceptable and idiomatic way to implement error handling. If something goes wrong in an inner loop, you can just break out of all the loops and go to the failure state. e.g. https://stackoverflow.com/questions/788903/valid-use-of-goto-for-error-management-in-c https://stackoverflow.com/questions/788903/valid-use-of-goto...
nhaehnle 13y ago
Since C has neither garbage collection nor the RAII pattern of C++, it is very common for C functions to have a cleanup section at the end, where allocated memory and other resources are freed again. In many C projects (including the Linux kernel) it is a common and accepted pattern to jump into the right position of the cleanup sequence using a goto.
wolf550e 13y ago
The correct way to do error handling in C is using goto statements. Dijkstra did not mean local goto statements. He meant something you will not find in any C code you are likely to use on a rhel/debian machine.
josteink 13y ago
Apart from the other reasons mentioned here, it probably translates to compact code which fits well within level-1 instruction cache in modern CPU when translated into assembly, without any need for additional lexical scopes and stack allocations.
EddSeabrook 13y ago
C doesn't have exceptions, so goto is commonly used to emulate that style of programming.

flurpitude 13y ago

Coming so soon after the Apple bug, it does make one wonder whether some or all of these are deliberate backdoors. Relevant musings by Bruce Schneier: https://www.schneier.com/blog/archives/2014/02/was_the_ios_ssl.html https://www.schneier.com/blog/archives/2014/02/was_the_ios_s...

weavejester 13y ago
Why would coming soon after the Apple bug make it more likely this bug was deliberate?
rmc 13y ago
Or the attention is now on "does your SSL cert handlying code have any shortcuts? Let's everyone double and triple check"
ksk 13y ago
Two heads in a row.. the coin must be rigged ;)

josteink 13y ago

Just checked my Ubuntu boxes. Update has been pushed and is ready to apt-get.

shavenwarthog2 13y ago
Yes. For others: 1) consider installing the "unattended-upgrades" tool, to install security updates via cron. https://help.ubuntu.com/community/AutomaticSecurityUpdates https://help.ubuntu.com/community/AutomaticSecurityUpdates 2) specific Ubuntu Security Notice on GnuTLS: http://www.ubuntu.com/usn/usn-2121-1/ http://www.ubuntu.com/usn/usn-2121-1/ 3) List specific package affected: dpkg-query -W libgnutls* libgnutls-openssl27:amd64 2.12.23-1ubuntu4 libgnutls26:amd64 2.12.23-1ubuntu4 I'm on Linux Mint, and the above seem to show that I'm protected. Yay!
- wreegab 13y ago
  For Saucy, the fix is in: .../ubuntu/+source/gnutls26/2.12.23-1ubuntu4.2 Yours is: .../ubuntu/+source/gnutls26/2.12.23-1ubuntu4 See: https://launchpad.net/ubuntu/+source/gnutls26/2.12.23-1ubuntu4.2">https://launchpad.net/ubuntu/+source/gnutls26/2.12.23-1ubuntu4.2 https://launchpad.net/ubuntu/+source/gnutls26/2.12.23-1ubunt...
deleted 13y ago
[deleted]
deleted 13y ago
[deleted]

vezzy-fnord 13y ago

Makes me wonder how long this may have been used as a 0-day.

bbanyc 13y ago

So which projects actually use GnuTLS as opposed to OpenSSL (Apache, lighttpd, nginx) or NSS (Firefox, Chrome)? I'm aware of Debian linking some packages against GnuTLS to avoid the supposed GPL incompatibility issue with OpenSSL, but the only thing I've seen that explicitly uses GnuTLS is Emacs 24.

aroch 13y ago
Apache can (and maybe should) use gnuTLS
- josh-wrale 13y ago
  Please expound on why you believe Apache 'maybe should' use gnuTLS.
  - aroch 13y ago
    Back when I still used Apache it didn't have support for TLS 1.1/1.2 due to the dep on OpenSSL and thus none of the better FS ciphers. So compiling against gnuTLS allowed for those. That's now been rectified.

acc00 13y ago

Commit introducing the bug: https://www.gitorious.org/gnutls/gnutls/commit/0fba2d908da6d0df821991ea5fdbeeda0f4ff089 https://www.gitorious.org/gnutls/gnutls/commit/0fba2d908da6d...

zwily 13y ago
And the fix: https://www.gitorious.org/gnutls/gnutls/commit/6aa26f78150ccbdf0aec1878a41c17c41d358a3b?diffmode=sidebyside#lib/x509/verify.c https://www.gitorious.org/gnutls/gnutls/commit/6aa26f78150cc...
acqq 13y ago
Commit: #0fba2d9 "Improved the certificate generation stuff."
- snarfy 13y ago
  On one hand this makes me wary of the quality of GnuTLS source in general, and on the other I know I am guilty of similar commit messages.
elwell 13y ago
wow "10 years ago" and git was only released 9 years ago
- Jach 13y ago
  Your comment made me pause while reading this thread -- what exactly is surprising about that? Repo migration is a thing...
Estragon 13y ago
Maybe the patch wouldr have gotten more attention if he'd broken it up into smaller chunks.

JshWright 13y ago

Disclaimer: My understanding of the goto fail bug is based on agl's writeup, and my understanding of the GnuTLS bug is limited to this article. In both of these cases, it seems the code starts with the assumption that the cert is valid and then tries to find various conditions to invalidate it. Isn't that backwards? Why not start with an assumption that the cert is untrusted until you've proven otherwise?

pg_is_a_butt 13y ago
because AMURIKUH
tptacek 13y ago
That's not what happened here. The problem is that the logic of the validation predicate was broken. In fact, this bug happened after the code had determined the cert was invalid; it just signaled the error improperly.
guscost 13y ago
This is an interesting question. I agree that invalid-by-default makes sense when reasoning about the higher-level system, but regarding the actual Boolean logic it seems that if a critical condition is broken the particular formulation will not make much of a difference. Additionally, it seems that in certain situations having several plain-if conditionals set the valid state to `1` would be less robust than having several conditionals set it to `0`. In the first case if any one of the conditions have bugs the false valid state can happen, whereas in the second case the last conditional to execute would have to contain the bug. Can anyone else comment on this? Are there relevant theories and/or best practices which have been discussed in the security community?
- JshWright 13y ago
  What about several conditionals that set various elements of a struct to 1, and the cert is valid iff all elements are 1. At least that way a skipped check (i.e. goto fail;) wouldn't result in a false positive...

HallOfQuotes 13y ago

For to be free is not merely to cast off one's chains, but to live in a way that respects and enhances the freedom of others. Read more at http://www.hallofquotes.com/quote/18608.html#OiEf9RybEMiL0J0w.99 http://www.hallofquotes.com/quote/18608.html#OiEf9RybEMiL0J0...

afhsfsfdsss88 13y ago

Can we all finally accept the fact that what is most needed now is not a new whizbang but a comprehensive review of all of the core pieces of software that we depend on as a base for making new whizbangs? How many critical and ancient bugs still remain undiscovered? Everyday there is a new Telegram, Cryptocat, etc. all presumably being constructed on top of insecure libraries. What progress can we make with such shaky foundations? There has been word that the Linux kernel devs are considering slowing new feature adoption for a time while focusing on bug discovery and elimination. PLEASE, EVERYONE ELSE CONSIDER DOING THE SAME.

newman314 13y ago
At a minimum, commonly used security packages should be reviewed and OS distribution maintainers commit to updating to latest versions of said packages regardless of the age of the OS. For example, Ubuntu 12.04 LTS uses an older version of OpenSSH and OpenSSL. There should be no reason why Ubuntu (and others) can't commit to updating to the latest versions so that features in say OpenSSH 6.5p1 are avail. BTW, saying that you can compile and install this yourself is noted beforehand but honestly, how many people do that on a regular basis? What I'm getting at is that security software can and should be held to a higher and current standard precisely because it affects so many other pieces of software in fundamental ways. It's not a big deal if the latest version of bc is not installed but it sure is if GnuTLS or OpenSSL is broken.

0xdeadbeefbabe 13y ago

What's with the back button ARS? Helping me stay off hn?

thrownaway2424 13y ago

Demand unit tests and comments. I mean, I was incensed by the quality of the Apple code, but this code is just as bad: * Checks if the issuer of a certificate is a * Certificate Authority, or if the certificate is the same * as the issuer (and therefore it doesn't need to be a CA). * * Returns true or false, if the issuer is a CA, * or not. */ static int check_if_ca (gnutls_x509_crt_t cert, gnutls_x509_crt_t issuer, unsigned int flags) { Sure, returns "true" or "false" which are not things in C. This actually returns either 0 or 1. Many C library functions return 0 for OK and non-zero for error. This one returns 0 for error and 1 for OK. Imagine you are reviewing the a call site of this code: if (check_if_ca(...)) { // CA is valid, proceed } vs. if (check_if_ca(...) == 0) { // CA is valid, proceed } To the reviewer who is accustomed to strcmp, either of these might appear to be fine, meaning that the reviewer (or even the author) has to carefully check the documentation of this function. What else is wrong with this signature? For one thing it would be easy to swap the arguments around: if (check_if_ca(cert, issuer, flags)) ... if (check_if_ca(issuer, cert, flags)) ... What's the difference? They both look reasonable. What are the valid/relevant values of |flags|? Would it be easier to comprehend |flags| if it were an options struct, e.g. GNUTLSCertificateVerificationOptions opts; opts.set_allow_rsa_md2(true); ... cert.Verify(opts); ? Would it be easier to verify the correctness of a call site of check_if_ca if it looked like this: if (issuer_cert.IsCA() || cert == issuer_cert) ... Where are the unit tests. The unit tests should be right here in the lib directory as whatever_unittest.c, adjacent to the source file they are testing, so you don't have to go groping around in the tree trying to find the relevant test, if it even exists. By the way, I found no test that calls this function. Basically this code has all the same problems as the Apple code, except for the mixed tabs/spaces stuff (as far as I can tell). It would be shameful for any professional programmer or organization of programmers to create this code.

sillysaurus3 13y ago
What's necessary is to get at least two experienced cryptographers thinking about every piece of security-critical code, because that's what will prevent bugs. It's also why security audits are so expensive: they work. The code absolutely should have had clearer comments, since if every step were commented then some of the return value confusion may have been avoided. The style of the code itself probably isn't as terrible as it seems at first glance, though. It's also not easy to write useful unit tests for a security stack.

deleted 13y ago

[deleted]

stonogo 13y ago

This is not a bug that leaves "linux" open to anything. It's a GnuTLS bug, and you should be using openssl anyway.

murftown 13y ago
This
michh 13y ago
Why should I be using OpenSSL other than this bug?
- stonogo 13y ago
  GnuTLS exists as a project almost exclusively due to ideology concerns -- people who prefer GPL do not like OpenSSL's license. That's not to say that technically-capable people are not behind it, but there are not as many as involved with OpenSSL. There are very few technical advantages to GnuTLS, and almost all of them have been transient (as in, certain protocols and ciphers have been supported in GnuTLS before other libraries). I do not have the time to go over why other libraries occasionally lag behind GnuTLS, but I can specify, for instance, that OpenSSL code goes through a more thorough and lengthy review process before it gets 'shipped' (inasmuch as that term applies to not-for-profit software). Code that supports GnuTLS can easily be made to support OpenSSL (or several other such libraries). It really is a matter of which license you prefer, and licensing should never be a consideration in security.
nzp 13y ago
While I agree with most of these two sentences, you can't really be sure there's no such bug in OpenSSL. I mean, not this specific bug, but a similar hard-to-imagine-random-situation bug.

rdl 13y ago

SSL fuzzing seems like it could be a really profitable area of research. I wonder why there aren't better conformance testing tools for SSL (other than SSL being kind of hideously baroque).

hiphopyo 13y ago

Choose OpenBSD for your Unix needs. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant firewall PF, and the world's most elegant mail server OpenSMTPD. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.

gonzo 13y ago
unfortunately, it is as performant as a pig in winter mud.

benihana 13y ago

So I guess the whole meme of "if the code was open to scrutiny, this bug wouldn't have happened" doesn't seem to be so valid now. There was legitimate outrage on Hacker News that Apple could allow such a bug, and that it was an indicator of the evil of closed source systems.

mattjaynes 13y ago

Does anyone know if this affects any of the popular configuration management tools like Puppet, Chef, SaltStack, etc?

vacri 13y ago
If you're on a Debian derivative, you can find out which installed packages depend on an item with "aptitude why [foo]"

laumars 13y ago

As someone who uses tends to compile most things against openssl, I was wondering if someone could answer how widespread gnutls usage is?

ufmace 13y ago

Does this make anyone else's conspiracy antenna twitch a bit? The Apple one was only a little suspicious in that way. A bug in another major crypto library that weakens it in a very similar way makes it look a little more suspicious. Since this is OSS, the investigation of the source control logs will probably be a bit more public. I wonder if they'll find anything interesting.

hoers 13y ago

Is there a list somewhere of which applications use GnuTLS?

niio 13y ago

albertop 13y ago

So I wonder where are all commenters blasting Apple for careless coding. Crypto is brittle.

murftown 13y ago

How many apps really use GnuTLS anyways? Apache doesn't by default. SSH doesn't. Are most RedHat installations therefore not really affected?

balls187 13y ago

Windows is bound to be next. #it_comes_in_threes

elwell 13y ago

But I thought open-source is immune to slip-ups like this? /s

greatsuccess 13y ago

After Apple and now GNU, henceforth no SSL distribution should be accepted at face value without proof of continuous automated testing results. Period. This is a scandal now.

deleted 13y ago

[deleted]

arunc 13y ago

That's a good hype for GnuTLS, but most of the packages that I know of uses OpenSSL - Apache, Nginx and so on. So it doesn't really matter.

ybaumes 13y ago

Since 2005? 10 years long in production? And while the code is open, no-one ever seen the bug? Is that the power of open source??

joelthelion 13y ago

Is there a tool to check if you're affected?