Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

16years.secvuln.info

Post reply on HN
Print view View original

11–20 of 68 posts

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

#11

Post by aaronmdjones »

jsiepkes wrote: post #8
yjftsjthsd-h wrote: post #2

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…

While you can forge the DKIM signature there is a good chance there is also SPF configured. SPF tells which servers are allowed to send mail for the domain. So your email would likely still end up in the spam folder.

DMARC only requires one of SPF or DKIM to pass. DKIM passing and SPF failing won't deter DMARC; the message will land in the inbox.

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

#12

Post by grayhatter »

gsich wrote: post #7

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

This is why you don't change any code without understanding.

Is it broken? no? then don't fix it! I find it super hard to believe this wasn't the very first supply chain attack discovery. (If anyone knows of a verified early one, I'd love to be corrected!)

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

#13

Post by Kwpolska »

zer00eyz wrote: post #10

I think the maintainer needs to update the OpenSSL package and remove all the networking features.... https://news.ycombinator.com/item?id=40320166 To soon? (Note I run Debian all over the place, and am generally happy with it.)

Well, this OpenSSL bug was caused by Debian maintainers messing with the code they package too much…

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

#14

Post by Karellen »

grayhatter wrote: post #12
gsich wrote: post #7

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

This is why you don't change any code without understanding. Is it broken? no? then don't fix it! I find it super hard to believe this wasn't the very first supply chain attack discovery. (If anyone knows of a verified early one, I'd love to be corrected!)

If it were a supply chain attack, I find it hard to believe that a) it would have originated from Debian at all, and b) that the people making the patch would have posted to the openssl-dev mailing list to ask their opinion on the correctness of the patch before including/shipping it.

https://lwn.net/Articles/282038/

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

#15

Post by ris »

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.

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

#16

Post by woodruffw »

westurner wrote: post #6
jmclnx wrote: post #3

So to check your keys, you are asked to grab a pip package. That is OK, but I heard there were lots of security issues with pips too. From one issue to maybe another ? If you are worried, I would just recreate your keys.

PyPI has only implemented the "server signs whatever's uploaded with that account" part of TUF; there are no Publisher Signatures for packages uploaded to pypi (because GPG ASC support was removed from PyPI, the ad-hoc signature support was removed from wheel, and only server signatures are yet implemented). https://SLSA.dev/ recommends TUF and Sigstore.dev and trusted containers for build-signing. Someday, Twine sho…

PyPI doesn’t currently implement any part of TUF in a public facing manner, so I’m not sure where you got that from :-). There’s some limited deployment experiments with rstuf, but these are not part of any current server-side package signing scheme.

PEP 740 does the rest of what you’ve described, however. And twine already has initial support for it, although it isn’t part of a release yet.

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

#17

Post by tredre3 »

ris wrote: 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.

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

#18

Post by hxelk1 »

ris wrote: 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.

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

#19

Post by asveikau »

tredre3 wrote: post #17
ris wrote: 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.

That was one factor of multiple, and the malicious actor chose to exploit it that way. liblzma is in enough critical stuff that they could have chosen to exploit something different had it not been for that.

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

#20

Post by mistrial9 »

tredre3 wrote: post #17
ris wrote: 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.

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
Post reply on HN