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

41–50 of 68 posts

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

#41

Post by saghm »

throwup238 wrote: post #39
cassianoleal wrote: post #37

Earlier quoted context omitted.

Right... I may have wrongly named Arch in my comment. Thanks for the correction. I'm curious about Arch's claim that "the build script was configured to only inject the bad code in Debian/Fedora based package build environments". Were Debian and Fedora specifically targetted, and the other distros who also got affected just happened to use similar packaging routines, or is this claim a guess?

Me too, especially since many packages on Arch begin by downloading the official .deb/.rpm

Does this happen for official packages or just the AUR? I was pretty sure that when possible they build the packages from source themselves rather than bundling pre-existing binaries, and I'd assume that they wouldn't likely have the sources in the final package. IIRC Debian doesn't even like to bundle the headers in with libraries in preference of splitting them off into a separate file, so I'd be kind of shocked if they put the entire source of each library in the .deb files they distribute.

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

#42

Post by rcxdude »

aspenmayer wrote: post #32
throwaway6272 wrote: post #9

Earlier quoted context omitted.

I did this, kind of. I was interviewing for a financial company that went to some effort to hide their location for operational security, met them at a local cafe where we talked about physical security, and then casually mentioned that I was staying at an airbnb across the road from their office and we could walk back together. It took a couple of calls to find someone who happily told me their registered address. T…

Wouldn't their registered address be public information? I understand that corporations may use agents/lawyers for that kind of thing, with layers of shell companies, but in theory this kind of info is able to be discovered and deduced from tax records, incorporation documents, and for publicly traded companies, SEC filings, etc. Cool story! I'm glad you got the job! Anything else about your sleuthing you'd care to a…

A business needs a registered address, but it doesn't need to be the address of their main offices. It's quite common to have a registered address which is just a forwarding agency.

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

#43

Post by grawlinson »

saghm wrote: post #41
throwup238 wrote: post #39

Earlier quoted context omitted.

Me too, especially since many packages on Arch begin by downloading the official .deb/.rpm

Does this happen for official packages or just the AUR? I was pretty sure that when possible they build the packages from source themselves rather than bundling pre-existing binaries, and I'd assume that they wouldn't likely have the sources in the final package. IIRC Debian doesn't even like to bundle the headers in with libraries in preference of splitting them off into a separate file, so I'd be kind of shocked if…

Arch package maintainer here; we generally encourage building from source for packages provided by the official repositories. As far as I know, we only ship pre compiled binaries if there is no source available, i.e. commercial programs such as reaper.

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

#44

Post by CJefferson »

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.

Two open source programs I work on have had bad patches added by packagers.

This one was special because it lead to a massive security issue, rather than just annoyed users who had bugs only because of packaging patches.

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

#45

Post by [deleted] »

tedunangst wrote: post #33
anonbanker wrote: post #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.tedunangs…

I don't think that has anything to with this, though.

[deleted]

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

#46

Post by amaranth »

b112 wrote: post #34
hxelk1 wrote: post #22

Earlier quoted context omitted.

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.

When the init system won't reliably start openssh, and insists the only fix is to patch, then blame the horrible init system. And that was what happened with systemd.

sd_notify is for additional (useful) functionality, it would work fine without it. You can tell because it works on arch.

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

#47

Post by aspenmayer »

rcxdude wrote: post #42
aspenmayer wrote: post #32

Earlier quoted context omitted.

Wouldn't their registered address be public information? I understand that corporations may use agents/lawyers for that kind of thing, with layers of shell companies, but in theory this kind of info is able to be discovered and deduced from tax records, incorporation documents, and for publicly traded companies, SEC filings, etc. Cool story! I'm glad you got the job! Anything else about your sleuthing you'd care to a…

A business needs a registered address, but it doesn't need to be the address of their main offices. It's quite common to have a registered address which is just a forwarding agency.

I guess you could mail a cellphone or AirTag to their registered address, then even if they find it and don’t forward it, you could follow the person(s) who fetch or deliver the mail to the company location.

You could maybe even skip the mailing step and just watch the registered address and trace the movements of everyone who visits that location.

Do you have any other methods you can think of?

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

#48

Post by thenickdude »

kbolino wrote: post #40
aaronmdjones wrote: post #11

Earlier quoted context omitted.

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.

That is a common DMARC configuration but not the only one. The failure tolerance is configurable.

I don't believe this is true, the only knob to tune is for relaxed or strict alignment checks for DKIM and SPF.

How do you configure DMARC to require both of DKIM and SPF?

The RFC says:

https://datatracker.ietf.org/doc/html/rfc7489#section-4.2

   A message satisfies the DMARC checks if at least one of the supported
   authentication mechanisms:

   1.  produces a "pass" result, and

   2.  produces that result based on an identifier that is in alignment,
       as defined in Section 3.

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

#49

Post by [deleted] »

kbolino wrote: post #40
aaronmdjones wrote: post #11

Earlier quoted context omitted.

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.

That is a common DMARC configuration but not the only one. The failure tolerance is configurable.

[deleted]

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

#50

Post by Atotalnoob »

aspenmayer wrote: post #47
rcxdude wrote: post #42

Earlier quoted context omitted.

A business needs a registered address, but it doesn't need to be the address of their main offices. It's quite common to have a registered address which is just a forwarding agency.

I guess you could mail a cellphone or AirTag to their registered address, then even if they find it and don’t forward it, you could follow the person(s) who fetch or deliver the mail to the company location. You could maybe even skip the mailing step and just watch the registered address and trace the movements of everyone who visits that location. Do you have any other methods you can think of?

Watching the location is a bad idea. I’d hazard a guess that most forwarding agencies have more than 1 customer, so you’ll be on a bunch of wild goose chases.

Also forwarding agencies probably don’t visit the clients locations often.

Post reply on HN