[HN Gopher] 16 years of CVE-2008-0166 - Debian OpenSSL Bug
___________________________________________________________________
16 years of CVE-2008-0166 - Debian OpenSSL Bug
Author : todsacerdoti
Score : 126 points
Date : 2024-05-12 09:19 UTC (13 hours ago)
(HTM) web link (16years.secvuln.info)
(TXT) w3m dump (16years.secvuln.info)
| yjftsjthsd-h wrote:
| 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 lawyer first, but the _entertaining_ answer would
| surely be to tell them about the problem in an email from their
| own domain? (Though seriously, double-check that that 's not
| illegal; funny isn't worth getting arrested.)
| Sebb767 wrote:
| That's the IT sec version of placing your CV on their server to
| apply :)
|
| That being said, a company which is that lax with reported
| vulnerabilities is not likely to handle "fun" well and even if
| what you are doing is legal, being involved in a lawsuit is no
| fun and probably not worth it, since, in the end, you are
| trying to help them.
| aspenmayer wrote:
| > That's the IT sec version of placing your CV on their
| server to apply :)
|
| Has this actually ever happened or been solicited? That's an
| interesting thought experiment.
|
| https://en.wikipedia.org/wiki/Calling_card_(crime)
|
| https://en.wikipedia.org/wiki/Website_defacement
|
| https://attrition.org/mirror/
|
| https://www.zone-h.org/archive
| throwaway6272 wrote:
| 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. They were creeped out but hired me anyway.
| aspenmayer wrote:
| 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 add? I'm intrigued.
| jsiepkes wrote:
| 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.
| aaronmdjones wrote:
| 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.
| hxelk1 wrote:
| 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.
| jmclnx wrote:
| 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.
| westurner wrote:
| 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 should prompt a PyPI package uploader to sign
| the package before uploading it, and download it to (prime the
| CDN cache and) check the Publisher and Package repo
| signature(s) at least once.
| woodruffw wrote:
| 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.
| gsich wrote:
| That's why you don't change upstream code without reason.
| grayhatter wrote:
| 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!)
| Karellen wrote:
| 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/
| yjftsjthsd-h wrote:
| > 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.
| zer00eyz wrote:
| 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.)
| Kwpolska wrote:
| Well, this OpenSSL bug _was_ caused by Debian maintainers
| messing with the code they package too much...
| ris wrote:
| 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.
| tredre3 wrote:
| The xz backdoor was caused by packagers patching OpenSSH. Just
| because it was caught you don't get to pretend it doesn't
| count.
| asveikau wrote:
| 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.
| mistrial9 wrote:
| 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
| hxelk1 wrote:
| 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.
| bbarnett wrote:
| 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.
| dgrunwald wrote:
| 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.
| kemotep wrote:
| 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?
| arp242 wrote:
| 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.
| hxelk1 wrote:
| I believe the xz backdoor relied on Debian patching OpenSSH
| with libsystemd to work.
| cassianoleal wrote:
| _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.
| Latty wrote:
| 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...
| tetha wrote:
| >"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.
|
| This is such a weird formulation though, because "other
| distributions" apparently included insignificant parts of
| the linux landscape like Fedora (i.e. the testing variant
| of the RedHat world) and SUSE.
|
| And if the three largest upstream distris in the linux
| world have this mistake, calling that "Well some distris,
| but screw mostly Debian" doesn't sound like a strong
| point.
| Latty wrote:
| I wasn't claiming Debian were somehow singularly at
| fault, the poster just specifically said Arch was also
| vulnerable, which wasn't true.
| anonbanker wrote:
| 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
| tedunangst wrote:
| I don't think that has anything to with this, though.
___________________________________________________________________
(page generated 2024-05-12 23:00 UTC)