3 ms·

I don't think that's a threat model that OpenSSH should waste too much time on. Ultimately this is malicious code in the build machine compiling a critical syst

I don't think that's a threat model that OpenSSH should waste too much time on. Ultimately this is malicious code in the build machine compiling a critical system library. That's not reasonable to defend against. Keep in mind that upstream didn't even link to liblzma. Debian patched it to do so. OpenSSH should defend against that too?

CanaryLayout 3y ago
any one of us if we sat on the OSSH team would flip the middle finger. What code is the project supposed to write when nothing on main dyn loaded liblzma. It was brought in from a patch they don't have realistic control over. This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it.
- shzhdbi09gv8ioi 3y ago
  > This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it. Not at all, it is a distro issue because a few distros such as Debian chose to patch openssh to bring in systemd support [1]. Other systemd-based distros like Arch Linux remains unaffected because they don't carry this patch. 1: https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/patches/systemd-readiness.patch/ https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/pa...
  - b112 3y ago
    Yet Redhat and others applied this patch, as systemd is so incapable of reliably launching processes, that it kept killing sshd without it. What a complete failure of an init system's job, and the patch was applied due to systemd not resolving the issue in another way. This is the problem with systemd. Way, way way too much complexity.
    - streb-lo 3y ago
      systemd is just fine on Arch without this patch. It's not a systemd issue, it's a larger cultural issue with packagers increasing attack surface to make their lives easier.
      - b112 3y ago
        It absolutely, positively, 100% was added due to issues with systemd. Both Redhat and Debian and others applied this patch as a result. People didn't do it "just cause". https://bugzilla.redhat.com/show_bug.cgi?id=1381997 https://bugzilla.redhat.com/show_bug.cgi?id=1381997 Jakub Jelen 2016-10-12 08:40:44 UTC <snip> > Why do you want to avoid sd_notify()? Why to avoid this? Well, it is adding more systemd-specific bits and new build dependency to something that always worked well under other inits without any problems for years.
        streb-lo 3y ago
        They chose the worst solution to a problem that had multiple better solutions because of a pre-existing patch was the easiest path forward. That’s exactly what I’m talking about.
    - asveikau 3y ago
      I think the criticisms of systemd are valid but also tangential. I think Poettering himself is on one of the HN threads saying they didn't need to link to his library to accomplish what they sought to do. Lzma is also linked into a bunch of other critical stuff, including but not limited to distro package managers and the kernel itself, so if they didn't have sshd to compromise, they could have chosen another target.
      - b112 3y ago
        And yet: https://news.ycombinator.com/item?id=39878181 https://news.ycombinator.com/item?id=39878181 So no, as Pottering claimed, sshd would not be hit by this bug except for this systemd integration. I really don't care about "Oh, someone could have written another compromise!". What allowed for this compromise, was a direct inability for systemd to reliable do its job as an init system, necessitating a patch. And Redhat, Fedora, Debian, Ubuntu, and endless other distros took this route, because something was required, and here we are. Something that would not be required if systemd could actually perform its job as an init system without endless work arounds. Also see my other reply in this thread, re Redhat's patch.
        asveikau 3y ago
        I'm not the type to go out of my way to defend systemd and their design choices. I'm just saying the severity of this scenario of a tainted library transcends some of the legit design criticisms. If you can trojan liblzma you can probably do some serious damage without systemd or sshd.
        b112 3y ago
        Of course you can trojan other ways, but that can only be said, in this thread, in defense of systemd. After all, what you're saying is and has always been the case! It's like saying "Well, Ford had a design flaw in this Pinto, and sure 20 people died, but... like, cars have design flaws from time to time, so an accident like this would've happened eventually anyhow! Oh well!" It doesn't jive in this context. Directly speaking to this point, patched ssh was chosen for a reason. It was the lowest hanging fruit, with the greatest reward. Your speculation about other targets isn't unwarranted, but at the same time, entirely unvalidated.
- jethro_tell 3y ago
  Brought in from a patch they rejected to accept because of this exact risk
astrange 3y ago
It is possible to prevent libraries from patching functions in other libraries; make those VM regions unwritable, don't let anyone make them writable, and adopt PAC or similar hardware protection so the kernel can't overwrite them either.
- rwmj 3y ago
  That's already done, but in this case the attack happened in a glibc ifunc and those run before the patching protection is enabled (since an ifunc has to patch the PLT).
  - astrange 3y ago
    Sounds like libraries should only get to patch themselves. (Some difficulty with this one though. For instance you probably have to ban running arbitrary code at load time, but you should do this anyway because it will stop people from writing C++.)
    - rwmj 3y ago
      They're all in a single address space, there's nothing you can do to stop one part of a binary patching any other part.
      - astrange 3y ago
        I already said the way to do it in my previous comment. Don't let arbitrary code run before page permissions are locked down.
        rwmj 3y ago
        If you're running in the binary you can call mprotect(2), and even if that is blocked you can cause all kinds of mischief. The original motivation for rings of protection on i286 was so that libraries could run in a different ring from the binary (usually library in ring 2 and program in ring 3), using a call gate (a very controlled type of call) to dispatch calls from the binary to the library, which stops the binary from modifying the library and IIRC libraries from touching each other. But x86-64 got rid of the middle rings.

CanaryLayout 3y ago

any one of us if we sat on the OSSH team would flip the middle finger. What code is the project supposed to write when nothing on main dyn loaded liblzma. It was brought in from a patch they don't have realistic control over. This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it.

shzhdbi09gv8ioi 3y ago
> This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it. Not at all, it is a distro issue because a few distros such as Debian chose to patch openssh to bring in systemd support [1]. Other systemd-based distros like Arch Linux remains unaffected because they don't carry this patch. 1: https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/patches/systemd-readiness.patch/ https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/pa...
- b112 3y ago
  Yet Redhat and others applied this patch, as systemd is so incapable of reliably launching processes, that it kept killing sshd without it. What a complete failure of an init system's job, and the patch was applied due to systemd not resolving the issue in another way. This is the problem with systemd. Way, way way too much complexity.
  - streb-lo 3y ago
    systemd is just fine on Arch without this patch. It's not a systemd issue, it's a larger cultural issue with packagers increasing attack surface to make their lives easier.
    - b112 3y ago
      It absolutely, positively, 100% was added due to issues with systemd. Both Redhat and Debian and others applied this patch as a result. People didn't do it "just cause". https://bugzilla.redhat.com/show_bug.cgi?id=1381997 https://bugzilla.redhat.com/show_bug.cgi?id=1381997 Jakub Jelen 2016-10-12 08:40:44 UTC <snip> > Why do you want to avoid sd_notify()? Why to avoid this? Well, it is adding more systemd-specific bits and new build dependency to something that always worked well under other inits without any problems for years.
      - streb-lo 3y ago
        They chose the worst solution to a problem that had multiple better solutions because of a pre-existing patch was the easiest path forward. That’s exactly what I’m talking about.
  - asveikau 3y ago
    I think the criticisms of systemd are valid but also tangential. I think Poettering himself is on one of the HN threads saying they didn't need to link to his library to accomplish what they sought to do. Lzma is also linked into a bunch of other critical stuff, including but not limited to distro package managers and the kernel itself, so if they didn't have sshd to compromise, they could have chosen another target.
    - b112 3y ago
      And yet: https://news.ycombinator.com/item?id=39878181 https://news.ycombinator.com/item?id=39878181 So no, as Pottering claimed, sshd would not be hit by this bug except for this systemd integration. I really don't care about "Oh, someone could have written another compromise!". What allowed for this compromise, was a direct inability for systemd to reliable do its job as an init system, necessitating a patch. And Redhat, Fedora, Debian, Ubuntu, and endless other distros took this route, because something was required, and here we are. Something that would not be required if systemd could actually perform its job as an init system without endless work arounds. Also see my other reply in this thread, re Redhat's patch.
      - asveikau 3y ago
        I'm not the type to go out of my way to defend systemd and their design choices. I'm just saying the severity of this scenario of a tainted library transcends some of the legit design criticisms. If you can trojan liblzma you can probably do some serious damage without systemd or sshd.
        b112 3y ago
        Of course you can trojan other ways, but that can only be said, in this thread, in defense of systemd. After all, what you're saying is and has always been the case! It's like saying "Well, Ford had a design flaw in this Pinto, and sure 20 people died, but... like, cars have design flaws from time to time, so an accident like this would've happened eventually anyhow! Oh well!" It doesn't jive in this context. Directly speaking to this point, patched ssh was chosen for a reason. It was the lowest hanging fruit, with the greatest reward. Your speculation about other targets isn't unwarranted, but at the same time, entirely unvalidated.
jethro_tell 3y ago
Brought in from a patch they rejected to accept because of this exact risk

astrange 3y ago

It is possible to prevent libraries from patching functions in other libraries; make those VM regions unwritable, don't let anyone make them writable, and adopt PAC or similar hardware protection so the kernel can't overwrite them either.

rwmj 3y ago
That's already done, but in this case the attack happened in a glibc ifunc and those run before the patching protection is enabled (since an ifunc has to patch the PLT).
- astrange 3y ago
  Sounds like libraries should only get to patch themselves. (Some difficulty with this one though. For instance you probably have to ban running arbitrary code at load time, but you should do this anyway because it will stop people from writing C++.)
  - rwmj 3y ago
    They're all in a single address space, there's nothing you can do to stop one part of a binary patching any other part.
    - astrange 3y ago
      I already said the way to do it in my previous comment. Don't let arbitrary code run before page permissions are locked down.
      - rwmj 3y ago
        If you're running in the binary you can call mprotect(2), and even if that is blocked you can cause all kinds of mischief. The original motivation for rings of protection on i286 was so that libraries could run in a different ring from the binary (usually library in ring 2 and program in ring 3), using a call gate (a very controlled type of call) to dispatch calls from the binary to the library, which stops the binary from modifying the library and IIRC libraries from touching each other. But x86-64 got rid of the middle rings.