I really was expecting the headline to be "Debian invents predictable random numbers".
Debian has warned of a vulnerability in its cryptographic functions that could leave systems open to attack. The use of a cryptographically flawed pseudo random number generator in Debian's implementation of OpenSSL meant that potentially predictable keys were generated. Versions of Debian's OpenSSL packages starting with 0.9. …
The first of the two explanations is the correct one, Debian maintainers fixed a warning issued by the memory debugger Valgrind by commenting out the code instead of finding the route cause. Needless to say this was incredibly stupid of them. The code concerned allocated memory to the pool used when deriving the random number, commenting it out meant that the number of possible variations was reduced by a significant factor.
According to Ben Laurie of OpenSSL, the Debian maintainers never mentioned what they were doing to anyone at OpenSSL nor did they forward on the "fix". As a result no-one who actually knew the code was able to point out the mistake they were making.
Debian should revoke the permissions of the packager responsible and ensure that only qualified people are given such critical jobs. As Ben Laurie also notes, distributions should not be patching issues in their own copies without also sending patches upstream where they can be reviewed by people who know the code.
It's clearly a stupid mistake by someone in Debian and if they had followed procedures it should have been picked up a long time ago. However the error has now been detected and patched, and people know what to do to correct their systems.
I've already upgraded all my exposed systems and most of my non-exposed systems.
All software has bugs, even open source secure tools from a reputable security concious Linux distro. People using Debian or Mac OS X etc should not get smug and think just because Windows gets most of the attention of the bad people that their system is invulnerable, even though Unix/Linux systems are better designed and built NOTHING IS PERFECT!
At least unlike some vendors who post vague warnings and patches months after the event, with Linux and Debian, nothing is held back...
"I've already upgraded all my exposed systems and most of my non-exposed systems."
Upgrading fixes the bug, but not the effects. You should also re-generate your keying material. SSH host keys. SSH user keys. SSL webserver/mailserver keys/certificates. OpenVPN keys. DNSSEC keys. (yeah, right :-) And what with all the key churn and the amount of fingerprint verification that usually happens, isn't this a great time for some MITM games too. (Might be a useful time to start publishing SSHFP DNS records and enable checking in your clients).
The vulnerability notice includes a URL to a scanner which detects keys with weak keying material, including for remote SSH systems. The astute reader will notice that this doesn't just help identify problematic keys on your own networks...
Uninitialised ram space is a lousy source of entropy anyway. It's far too predictable. So simply omitting stirring this buffer's-worth into the pot shouldn't have made any major difference.
If you look at the source, the next thing it goes and does is fills it with stuff from /dev/urandom or /dev/random. It even has a comment about trying for up to 10ms per file. So the uninitialised data is really only a last resort fallback in case there wasn't enough entropy in the system pool. And also no entropy-gathering daemon running.
Conceivably this could only be a problem because there's some other, as yet unacknowledged, problem with the kernel's entropy pool? That's a bit AFDBish, I guess.
Actually OpenSSL people were asked about this on their mailing list...
"What I currently see as best option is to actually comment out those 2 lines of code. But I have no idea what effect this really has on the RNG. The only effect I see is that the pool might receive less entropy. But on the other hand, I'm not even sure how much entropy some unitialised data has.
What do you people think about removing those 2 lines of code?"
This post has been deleted by its author
The media wants sensations. This is one of those times. Consider a headline "A cryptographic service has a flaw!". It implies that the flaw is serious enough to consider newsworthy, but never mentions the exploitability of the said flaw; which in this case is practically non-existant.
The bug report reference is correct, but the patch in it is not the problematic change (read the patch in the context of the code it changes if you're unsure about this). The Debian maintainer ignored it and made their own change elsewhere.
It's also not in fact true that OpenSSL upstream were not consulted about it; indeed it seems Kurt got a go-ahead (http://marc.info/?l=openssl-dev&m=114652287210110&w=2) in a response from a member of the OpenSSL development team.
"The media wants sensations. This is one of those times. Consider a headline "A cryptographic service has a flaw!". It implies that the flaw is serious enough to consider newsworthy, but never mentions the exploitability of the said flaw; which in this case is practically non-existant." ..... By Gleb Posted Wednesday 14th May 2008 03:08 GMT
Which in this case, Gleb, is you crying wolf. And whether that is a question or a statement is dependent upon and relative to what you know about the Securing Code with Permissible NEUKlearer Links.
I wasn't sure about the exploitability of this bug and it would be good if the The Reg could find out. I'm no crypto-expert, but it seems to me that the bug reduced the number of keys to somewhere around 250,000, in which case I would have thought the encryption would be trivially compromised. Whether I care or not is a different story. My neighbours are luddites, my ISP is lazy and I trust most of the internet gateways in-between. That said, I'm sure someone does care.
I think this bug is probably worth the media circus.
You are correct, once the patch has been applied all keys need to be regerated, which is of course what I did - but did not say.
As of today all my systems, exposed or otherwise have been upgraded and keys have been regenrated.
The Debian Wiki contains a page which details the upgrade procedure: http://wiki.debian.org/SSLkeys
The keys are not only breakable by experienced crypto-analyst types. This bug has caused identical private SSH keys to be generated on totally unconnected hosts. As a result, logging into a remote server with my key a few days ago, I was logged in as somebody entirely different, who happened to have an identical private key, giving me access to their source code repo.
But, but... many eyes make all bugs shallow... ESR told me, so it must be true.
Meanwhile "At least unlike some vendors who post vague warnings and patches months after the event, with Linux and Debian, nothing is held back..."
Um... this was in the source tree for *two* *fucking* *years* - or 24 months after the event, in old money. And when it was finally patched in the public sources, it then took Debian five days to announce it to their customers. Ever wonder how many boxes you could compromise in five days given a clear run? Or do you simply assume that only the Good Guys read CVS commit logs?
zOMFG!!! I see what you mean now!
@@ -465,8 +465,10 @@
MD_Update(&m,(unsigned char *)&(md_c),sizeof(md_c));
+#if 0 /* Don't add uninitialised data. */
MD_Update(&m,buf,j); /* purify complains */
Yes, that's a whole world of different! The 363516 patch was the way they should have done it, but the effect of doing it down here in the lower layers is that they just discarded all the bytes that RAND_poll so carefully read out from /dev/urandom and passed to them! It discards /all/ the entropy, from any source, kernel daemon and all! D'oh and double d'oh!
;-) Technically, of course, this could be fixed by a one-line follow-up patch:
@@ -466,7 +466,7 @@
MD_Update(&m,(unsigned char *)&(md_c),sizeof(md_c));
-#if 0 /* Don't add uninitialised data. */
+#if 0 /* Don't add any data at all. */
MD_Update(&m,buf,j); /* purify complains */
There, that's correct now!
Umm...I use Umbongo...so I don't have several million best friends. At least they don't e-mail me much. Can you tell me where I can get so many best friends?
But on a more serious note, not being as much of a Linux geek as I'd like to be, what are the implications for desktop flavours of Debian/Ubuntu? I mean we're all using OpenSSL when we're ordering our pr0n and v!@gR4 are we not?
Microsoft is flagging up a security hole in its Service Fabric technology when using containerized Linux workloads, and urged customers to upgrade their clusters to the most recent release.
The flaw is tracked as CVE-2022-30137, an elevation-of-privilege vulnerability in Microsoft's Service Fabric. An attacker would need read/write access to the cluster as well as the ability to execute code within a Linux container granted access to the Service Fabric runtime in order to wreak havoc.
Through a compromised container, for instance, a miscreant could gain control of the resource's host Service Fabric node and potentially the entire cluster.
At The Linux Foundation's Open Source Summit in Austin, Texas on Tuesday, Linus Torvalds said he expects support for Rust code in the Linux kernel to be merged soon, possibly with the next release, 5.20.
At least since last December, when a patch added support for Rust as a second language for kernel code, the Linux community has been anticipating this transition, in the hope it leads to greater stability and security.
In a conversation with Dirk Hohndel, chief open source officer at Cardano, Torvalds said the patches to integrate Rust have not yet been merged because there's far more caution among Linux kernel maintainers than there was 30 years ago.
Interview In June, Purism began shipping a privacy-focused smartphone called Librem 5 USA that runs on a version of Linux called PureOS rather than Android or iOS. As the name suggests, it's made in America – all the electronics are assembled in its Carlsbad, California facility, using as many US-fabricated parts as possible.
While past privacy-focused phones, such as Silent Circle's Android-based Blackphone failed to win much market share, the political situation is different now than it was seven years ago.
Supply-chain provenance has become more important in recent years, thanks to concerns about the national security implications of foreign-made tech gear. The Librem 5 USA comes at a cost, starting at $1,999, though there are now US government agencies willing to pay that price for homegrown hardware they can trust – and evidently tech enthusiasts, too.
A security flaw in Apple's Safari web browser that was patched nine years ago was exploited in the wild again some months ago – a perfect example of a "zombie" vulnerability.
That's a bug that's been patched, but for whatever reason can be abused all over again on up-to-date systems and devices – or a bug closely related to a patched one.
In a write-up this month, Maddie Stone, a top researcher on Google's Project Zero team, shared details of a Safari vulnerability that folks realized in January this year was being exploited in the wild. This remote-code-execution flaw could be abused by a specially crafted website, for example, to run spyware on someone's device when viewed in their browser.
EndeavourOS is a rolling-release Linux distro based on Arch Linux. Although the project is relatively new, having started in 2019, it's the successor to an earlier Arch-based distro called Antergos, so it's not quite as immature as its youth might imply. It's a little more vanilla than Antergos was – for instance, it uses the Calamares cross-distro installer.
EndeavourOS hews more closely to its parent distro than, for example, Manjaro, which we looked at very recently. Unlike Manjaro, it doesn't have its own staging repositories or releases. It installs packages directly from the upstream Arch repositories, using the standard Arch package manager
pacman. It also bundles yay to easily fetch packages from the Arch User Repository, AUR. The
yay command takes the same switches as
pacman does, so if you wanted to install, say, Google Chrome, it's as simple as
yay -s google-chrome and a few seconds later, it's done.
Cisco has alerted customers to another four vulnerabilities in its products, including a high-severity flaw in its email and web security appliances.
The networking giant has issued a patch for that bug, tracked as CVE-2022-20664. The flaw is present in the web management interface of Cisco's Secure Email and Web Manager and Email Security Appliance in both the virtual and hardware appliances. Some earlier versions of both products, we note, have reached end of life, and so the manufacturer won't release fixes; it instead told customers to migrate to a newer version and dump the old.
This bug received a 7.7 out of 10 CVSS severity score, and Cisco noted that its security team is not aware of any in-the-wild exploitation, so far. That said, given the speed of reverse engineering, that day is likely to come.
Microsoft has made it official. Windows Subsystem for Linux 2 distributions are now supported on Windows Server 2022.
The technology emerged in preview form last month and represented somewhat of an about-face from the Windows giant, whose employees had previously complained that while the tech was handy for desktop users, sticking it on a server might mean it gets used for things for which it wasn't intended.
(And Windows Server absolutely had to have the bloated user interface of its desktop stablemate as well, right?)
Old-school editor fans, rejoice: some two and a half years after version 8.2, Vim 9 is here, and with a much faster scripting language.
The existing scripting language, Vimscript, remains and will still work. Only scripts beginning with the line
vim9script will be handled differently. The syntax changes are relatively modest; the important differences are in things like local versus global variables and functions, and that functions defined with
:def will be compiled before they are run. This allows many errors to be caught in advance, but more significantly, compiled functions execute from 10× to 1000× faster.
Version 21.3 of Manjaro - codenamed "Ruah" - is here, with kernel 5.15, but don't let its beginner-friendly billing fool you: you will need a clue with this one.
Manjaro Linux is one of the more popular Arch Linux derivatives, and the new version 21.3 is the latest update to version 21, released in 2021. There are three official variants, with GNOME 42.2, KDE 5.24.5 or Xfce 4.16 desktops, plus community builds with Budgie, Cinnamon, MATE, a choice of tiling window managers (i3 or Sway), plus a Docker image.
The Reg took its latest look at Arch Linux a few months ago. Arch is one of the older rolling-release distros, and it's also famously rather minimal. The installation process isn't trivial: it's driven from the command line, and the user does a lot of the hard work, manually partitioning disks and so on.
Good news for especially determined fans of Ubuntu's formerly in-house desktop: there's a new version.
Biting the hand that feeds IT © 1998–2022