Live data from Hacker News

16 years of CVE-2008-0166 – Debian OpenSSL Bug

16years.secvuln.info

21–30 of 68 posts

Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug

#21

I enjoyed the... I guess "narrative Q&A" style would be a good enough way to describe it? Regardless, it's fun. > The security team at Seznam - a Czech search engine and email provider - did not believe me when I reported this issue. They assume that as they are not actively using that key (beta._domainkey.seznam.cz), that means that it cannot be used to forge emails. This is, of course, not true. Maybe consult a law…

Couple of years ago, I noticed some weird Outlook headers on our internal company e-mails and decided to take a look. It turned out our company Outlook (or Exchange? who knows) mail server was configured to relay mail through some 3rd-party SPAM filter and the SPAM filter trusted some headers which weren't stripped on ingress. So you could send an e-mail with the headers set and they would reach the SPAM filter unmodified. As the company had a 3rd-party SPAM filter, all Outlook security was disabled. This allowed me to send e-mail with forged sender. Outlook in its amazing brilliance would attach the "sender's" company photo and show some kind of a "Trusted" badge or something.

I reported the issue and the admins weren't impressed. They insisted that this wasn't a major problem since the only way to make the e-mail appear to come from somebody in the company was to use you company account (outside e-mail would be filtered correctly). After some back and forth, I just told the admin to check his mailbox. It said something like, "if you don't think this is serious, you're fired" and it was "from" the CEO, with his smiling photo next to the name.

That finally did the trick.

EDIT: typos.

Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug

#22
post #17

Earlier quoted context omitted.

The xz backdoor was caused by packagers patching OpenSSH. Just because it was caught you don't get to pretend it doesn't count.

this is such a spin! that bug was two years worth of James Bond-level insertions into a situation that "was caused" by systemd ! if you want to get creative in the rewriting of fact

This isn't about systemd. OpenSSH is one of the most (if not the most) security-critical program in the distribution. Many systems run with just ssh enabled. That's why you don't mess with it.

Which library pulled the vulnerability in is mostly irrelevant.

Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug

#23
post #17
post #15

I love this case, because every time someone cites it as a reason packagers shouldn't patch upstream software I get to point out that they had to go back over a decade to find an example of it going bad. Soon it's going to be two decades.

The xz backdoor was caused by packagers patching OpenSSH. Just because it was caught you don't get to pretend it doesn't count.

You're confused there. The xz backdoor made use of a Debian OpenSSH patch, but it wasn't "caused" by it. Without the patch, the malicious xz maintainer could have written a different backdoor without making use of the OpenSSH patch -- for example, since debian packages are compressed with xz, the backdoor could have modified the sshd binary while unpacking the next OpenSSH security update. That would have been slower (attacker might have needed to wait a long time for a security update), and more discoverable since the modified file would be persisted to disk; but it also wouldn't have caused the performance issues that ended up in the discovery of the backdoor.

Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug

#24
post #18
post #15

I love this case, because every time someone cites it as a reason packagers shouldn't patch upstream software I get to point out that they had to go back over a decade to find an example of it going bad. Soon it's going to be two decades.

I believe the xz backdoor relied on Debian patching OpenSSH with libsystemd to work.

_sigh_ the backdoor was found because Debian also made those patches. Nearly all major distros were affected. The reason why Debian made the news is because the researcher who found the issue was using Debian. Had he been using Ubuntu, Arch, Fedora... those would have been in the news instead.

Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug

#25
Every day, Ted Unangst is vindicated more and more[1] for his work forking OpenSSL.

If you do a little digging, you'll see that there was no real technical reason why your distro of choice has abandoned implementing LibreSSL[2][3], or just never implemented it at all[4]. They just somehow wanted to keep using the faulty software with exploit mitigation countermeasures[5][6]. Totally organic.

1. https://flak.tedunangst.com/post/analysis-of-openssl-freelis...

2. https://wiki.gentoo.org/wiki/LibreSSL

3. https://github.com/void-linux/void-packages/issues/20935

4. https://lwn.net/Articles/841664/

5. https://marc.info/?l=openbsd-misc&m=139698531410614&w=2

6. https://marc.info/?l=openbsd-misc&m=139698608410938&w=2

Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug

#26
post #7

That's why you don't change upstream code without reason.

> That's why you don't change upstream code without reason.

They did have a reason; they were running analysis on the code, and one of their tools specifically called openssl out for using uninitialized memory, which is absolutely a red flag. But not to worry; rather than blindly patching it to fix the bug, they went out of their way to go ask upstream about it, appeared to get a favorable response to their patch, and then went ahead.

Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug

#27
post #17

Earlier quoted context omitted.

The xz backdoor was caused by packagers patching OpenSSH. Just because it was caught you don't get to pretend it doesn't count.

You're confused there. The xz backdoor made use of a Debian OpenSSH patch, but it wasn't "caused" by it. Without the patch, the malicious xz maintainer could have written a different backdoor without making use of the OpenSSH patch -- for example, since debian packages are compressed with xz, the backdoor could have modified the sshd binary while unpacking the next OpenSSH security update. That would have been slower…

It would be discoverable but only if you ran an additional hash to check the final binary after updating and checking with an out of band source what the hash of the binary should be.

How many people double check that apt actually updated the package to the right version, if it’s output is compromised?

Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug

#28
post #17
post #15

I love this case, because every time someone cites it as a reason packagers shouldn't patch upstream software I get to point out that they had to go back over a decade to find an example of it going bad. Soon it's going to be two decades.

The xz backdoor was caused by packagers patching OpenSSH. Just because it was caught you don't get to pretend it doesn't count.

Do you really think there was no other avenue? There are tons and tons of things that link against liblzma, including stuff that commonly gets run as root such as apt, udev, and grub.

Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug

#29
post #18

Earlier quoted context omitted.

I believe the xz backdoor relied on Debian patching OpenSSH with libsystemd to work.

_sigh_ the backdoor was found because Debian also made those patches. Nearly all major distros were affected. The reason why Debian made the news is because the researcher who found the issue was using Debian. Had he been using Ubuntu, Arch, Fedora... those would have been in the news instead.

According to Arch: "openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. Arch does not directly link openssh to liblzma", so at least one of your examples is wrong. That specific vulnerability was not in Arch.

The xz package was potentially vulnerable (although not in reality because "the build script was configured to only inject the bad code in Debian/Fedora based package build environments", while this was a choice by the attacker, it's still true the vulnerability wasn't there), but patching OpenSSH made OpenSSH specifically vulnerable when used with a malicious xz install.

https://archlinux.org/news/the-xz-package-has-been-backdoore...

Post reply on HN