A 'Severe' Bug Was Found In Libgcrypt, GnuPG's Cryptographic Library (helpnetsecurity.com) 39
Early Friday the principal author of GNU Privacy Guard (the free encryption software) warned that version 1.9.0 of its cryptographic library Libgcrypt, released January 19, had a "severe" security vulnerability and should not be used.
A new version 1.9.1, which fixes the flaw, is available for download, Help Net Security reports: He also noted that Fedora 34 (scheduled to be released in April 2021) and Gentoo Linux are already using the vulnerable version... [I]t's a heap buffer overflow due to an incorrect assumption in the block buffer management code. Just decrypting some data can overflow a heap buffer with attacker controlled data, no verification or signature is validated before the vulnerability occurs.
It was discovered and flagged by Google Project Zero researcher Tavis Ormandy and affects only Libgcrypt v1.9.0.
"Exploiting this bug is simple and thus immediate action for 1.9.0 users is required..." Koch posted on the GnuPG mailing list. "The 1.9.0 tarballs on our FTP server have been renamed so that scripts won't be able to get this version anymore."
A new version 1.9.1, which fixes the flaw, is available for download, Help Net Security reports: He also noted that Fedora 34 (scheduled to be released in April 2021) and Gentoo Linux are already using the vulnerable version... [I]t's a heap buffer overflow due to an incorrect assumption in the block buffer management code. Just decrypting some data can overflow a heap buffer with attacker controlled data, no verification or signature is validated before the vulnerability occurs.
It was discovered and flagged by Google Project Zero researcher Tavis Ormandy and affects only Libgcrypt v1.9.0.
"Exploiting this bug is simple and thus immediate action for 1.9.0 users is required..." Koch posted on the GnuPG mailing list. "The 1.9.0 tarballs on our FTP server have been renamed so that scripts won't be able to get this version anymore."
scary manyline functions manipulating raw buffers (Score:4, Interesting)
Surely some of the long scary functions manipulating buffers [gnupg.org] (click the show all lines) need to be carefully refactored into shorter simpler (possibly inlined) functions with lots of careful aggressive test cases. Not that I'm volunteering to do it at this point, so I'm not going to criticise those working on it, but, looking at the code we really need lots of people to learn how this stuff works and improve it.
Sure, that's what's included by default in C but it is possible to write it in ways that make it to be safer even without changing language.
Re: (Score:2)
120 lines in a single function.
Re: (Score:1)
Re: (Score:2)
Oh, you're right
Re: scary manyline functions manipulating raw buff (Score:2)
Almost correct.
It needs to be separated into aspects, not functions. So, layers.
A memory management aspect, a bounds checking aspect, a permission management aspect, etc, and the main pure algorithm aspect.
This is exactly what languages like Haskell, and features like carnage, err, garbage collectors and monad transformers were invented for.
Written with the right data types, it would have prevented all of those problems at *compile* time. And be about 10-15 easy to read lines.
Re: (Score:2)
Re: (Score:3)
Re: (Score:1)
Re: (Score:2)
oh great (Score:1)
I'm on gentoo stable and use libgcrypt 1.8.6. Is that version not vulnerable?
Re: (Score:3)
Did you even read the fucking summary?
Do you know you are on Slashdot ? People barely read the headline, never mind the summary and forget about reading the article
Re:oh great (Score:4, Informative)
You are fine. From the mailing list announcement:
Re: oh great (Score:2)
Somebody who uses Gentoo stable??
I thought you guys were a myth! That you would only exist in tales of ye olde stage-0-installers about BSD dagons and bank server knights on the quest for the ancient releases!
We are unworthy, oh Great One!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
My Gentoo system is running updates and libgcrypt is scheduled to downgrade to 1.8.6. It was on 1.9.0. 1.9.0 was installed on January 18.
Unit test (Score:1)
I'm able to develop much more quickly, with greater confidence and quality with unit tests. I can quickly test all sorts of scenarios that my code will encounter without having to incur delays from round-trip connections (in my case I'm connecting to a server).
Any software product that doesn't have these tests in place is build on quicksand.
Re:Unit test (Score:5, Insightful)
This is what you get when you don't unit test your code.
Don't be complacent - unit tests only test what you thought of to test.
Do fuzzing as well.
And review the code by eye every so often; you'll have learnt stuff since you wrote it.
Re: Unit test (Score:1)
Better yet is have someone else check your code, or at the very list its output on realistic input. Not always possible, but generally required in safety-of-life scenarios. Whoopsies like Boeing's Starliner aren't just embarrassments, they're career enders.
Re: (Score:1)
It also implies they don't even perform a smoke test before shipping a release.
Re: (Score:1)
Your comment is what you get when you have never even met a Real Programmer [catb.org].
Re: Unit test (Score:4, Insightful)
I never understood why people rely on unit tests.
Because if you do not trust code without unit tests, logically, since unit tests themselves are code, you can not trust them either. And would have to write unit tests for unit tests ad infinitum
I found the concept of statistical reliability much more trustworthy. As in: Several people write several independent implementations, and the more you got, the more you can rely on the results if they agree.
Yes, you will hardly ever get to six sixma, with its million of implementations. But if three flight computers are good enough for a plane, amd triple-mirroring is good enough for the best raid storage, then three implementations should be fine. Three actual working implementations.
Then all the tests would be reduced to a simple diff of the outputs.
Ideally with an exhaustive input range during staging. Or, alternatively, running all three implementations in parallel *in production*.
Re: (Score:2)
I never understood why people rely on unit tests.
Because they don't have a language that catches syntax errors or misspelled variable names at compile time.
Re: (Score:2)
Not a panacea either. Any non-trivial system has a non-trivial definition of how exactly it should behave. If each implementation defines its own, they'll never agree on anything non-trivial. But if all your implementations use the same definition, you're not safe from bugs in the definition itself. Of course, you're not safe from that with unit tests, either.
Re: (Score:3)
I never understood why people rely on unit tests.
I've never understood why people fly wildly to the extremes of any given debate...
Unit tests are one part of a good testing strategy. You shouldn't have only unit tests, but it's likely a bad idea if you have none. If unit test are hard to write, then your design it probably highly coupled and complex, often signs of poor design. And working at the lowest level it's easier to get high coverage with unit tests versus higher level tests (where the number of per
Re: (Score:2)
IMO writing tests becomes more of a pain when things like integration, automation / gui testing happen. It becomes a law of diminishing returns. I've seen tests so complex that
Re: (Score:2)
Unit tests don't tend to catch security issues, and they never test all possible edge cases.
Re: (Score:1)
This is the *wrong* library to disable checks! (Score:5, Insightful)
Who thought it was a good idea to disable basic bounds checks and the like for software like this??
Or use a language not made for this, like C.
This isn't a AAA game! The code's goal is not to be fast with the fenders flying off, but to be secure like a tank! And it certainly doesn't need low-level access or manual resource management outside of making sure used memory is overwritten after use.
Re: (Score:2)
Who thought it was a good idea to disable basic bounds checks and the like for software like this?? Or use a language not made for this, like C.
This isn't a AAA game! The code's goal is not to be fast with the fenders flying off, but to be secure like a tank! And it certainly doesn't need low-level access or manual resource management outside of making sure used memory is overwritten after use.
You most likely are incorrect about many of your assumptions. Most hardware comes with cryptographic acceleration that may actually require using assembly to take full advantage of. Most likely that is not the case, but some of these accelerations may not be possible in anything but C. That doesn't mean they can't minimize the amount of C used, of course, but it may actually be required. Also, the last time I used this library was to do many tens of thousands of signing operations per second and speed w
Re: (Score:1)
C has no bound checking.
This code is used in areas which are more performance-critical than an "AAA game".
Sorry but no part of your comment makes sense.
Re: (Score:2)
Re: (Score:3)
Depends. If the code originated in the mid-90s, it makes complete sense because the code has to be efficient. Even the early 2000s.
These days, there are many better options available so starting from scratch, you might burn extra CPU cycles doing those and dealing with the people who complain about software bloat.
And writing a cryptographic library is not easy - it's
Why isnâ(TM)t spice code analysis a thing in (Score:2)
Re: (Score:2)
Re: (Score:3)
I ran the the code through Codesonar and the exploit was found in about 3 minutes. For some reason these tools seem only used in engineering, aviation and aero space industries
... and other places where you can afford to pay it-you-need-to-ask-you-can't-afford-it prices for a software tool. Basically no-one smaller than a billion-dollar corporation, or perhaps a several-hundred-million-dollar corporation, can afford to use these things. Shout out to Coverity and PVS Studio for allowing free use for open source projects.