6 ms·

> In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seco

> In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). Mitigate by using fail2ban? Nice to see that Ubuntu isn't affected at all

simonjgreen 2y ago
For servers you have control over, as an emergency bandaid, sure. Assumes you are not on an embedded system though like a router.
- letters90 2y ago
  I didn't consider embedded, probably the biggest target for this.
ulrikrasmussen 2y ago
Where do you see that Ubuntu isn't affected?
- rs_rs_rs_rs_rs 2y ago
  >Side note: we discovered that Ubuntu 24.04 does not re-randomize the ASLR of its sshd children (it is randomized only once, at boot time); we tracked this down to the patch below, which turns off sshd's rexec_flag. This is generally a bad idea, but in the particular case of this signal handler race condition, it prevents sshd from being exploitable: the syslog() inside the SIGALRM handler does not call any of the malloc functions, because it is never the very first call to syslog(). No mention on 22.04 yet.
djmdjm 2y ago
Ubuntu isn't affected _by this exploit_
- jgalt212 2y ago
  as opposed to the other exploits not being discussed.
mmsc 2y ago
>Mitigate by using fail2ban? In theory, this could be used (much quicker than the mentioned days/weeks) to get local privilege escalation to root, if you already have some type of shell on the system already. I would assume that fail2ban doesn't block localhost.
- udev4096 2y ago
  How is local privilege escalation relevant here? Fail2ban should be able to block the RCE
  - mmsc 2y ago
    How is it not? If fail2ban isn't going to blocklist localhost, then it isn't a mitigation for this vulnerability because RCE implies LPE.
    - DEADMINCE 2y ago
      People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to. But, sure, in that case fail2ban won't mitigate, but that's pretty damn obviously implied. For 99% of people and situations, it will.
      - mmsc 2y ago
        >People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to It's going to apply to the amount of servers that an attacker has low-privileged access (think: www-data) and an unpatched sshd. Attackers don't care if it's an RCE or not: if a public sshd exploit can be used on a system with a Linux version without a public Linux LPE, it will be used. Being local also greatly increases the exploitability. Then consider the networks where port 22 is blocked from the internet but sshd is running in some internal network (or just locally for some reason).
        2y ago
nubinetwork 2y ago
Ubuntu has pushed an updated openssh.
paulmd 2y ago
> Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). AMD to the rescue - fortunately they decided to leave the take-a-way and prefetch-type-3 vulnerability unpatched, and continue to recommend that the KPTI mitigations be disabled by default due to performance costs. This breaks ASLR on all these systems, so these systems can be exploited in a much shorter time ;) AMD’s handling of these issues is WONTFIX, despite (contrary to their assertion) the latter even providing actual kernel data leakage at a higher rate than meltdown itself… (This one they’ve outright pulled down their security bulletin on) https://pcper.com/2020/03/amd-comments-on-take-a-way-vulnerability/ https://pcper.com/2020/03/amd-comments-on-take-a-way-vulnera... (This one remains unpatched in the third variant with prefetch+TLB) https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1017.html https://www.amd.com/en/resources/product-security/bulletin/a... edit: there is a third now building on the first one with an unpatched vulnerabilities in all zen1/zen2 as well… so this one is WONTFIX too it seems, like most of the defects TU Graz has turned up. https://www.tomshardware.com/news/amd-cachewarp-vulnerability-afflicts-epyc-server-cpus https://www.tomshardware.com/news/amd-cachewarp-vulnerabilit... Seriously I don’t know why the community just tolerates these defenses being known-broken on the most popular brand of CPUs within the enthusiast market, while allowing them to knowingly disable the defense that’s already implemented that would prevent this leakage. Is defense-in-depth not a thing anymore? Nobody in the world would ever tell you to explicitly turn off ASLR on an intel system that is exposed to untrusted attackers… yet that’s exactly the spec AMD continues to recommend and everyone goes along without a peep. It’s literally a kernel option that is already running and tested and hardens you against ASLR leakage. The “it’s only metadata” is so tired. Metadata is more important than regular data, in many cases. We kill people, convict people, control all our security and access control via metadata. Like yeah it’s just your ASLR layouts leaking, what’s the worst that could happen? And I mean real data goes too in several of these exploits too, but that’s not a big deal either… not like those ssh keys are important, right?
- JackSlateur 2y ago
  What are you talking about ? My early-2022 ryzen 5625U shows: Vulnerabilities: Gather data sampling: Not affected Itlb multihit: Not affected L1tf: Not affected Mds: Not affected Meltdown: Not affected Mmio stale data: Not affected Reg file data sampling: Not affected Retbleed: Not affected Spec rstack overflow: Vulnerable: Safe RET, no microcode Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Spectre v2: Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP always-on; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected Srbds: Not affected Tsx async abort: Not affected Only regular stuff
skeetmtp 2y ago
Ubuntu released patches though https://ubuntu.com/security/notices/USN-6859-1 https://ubuntu.com/security/notices/USN-6859-1
markhahn 2y ago
fail2ban just means an attacker would need to use many source IPs, not hard.

simonjgreen 2y ago

For servers you have control over, as an emergency bandaid, sure. Assumes you are not on an embedded system though like a router.

letters90 2y ago
I didn't consider embedded, probably the biggest target for this.

ulrikrasmussen 2y ago

Where do you see that Ubuntu isn't affected?

rs_rs_rs_rs_rs 2y ago
>Side note: we discovered that Ubuntu 24.04 does not re-randomize the ASLR of its sshd children (it is randomized only once, at boot time); we tracked this down to the patch below, which turns off sshd's rexec_flag. This is generally a bad idea, but in the particular case of this signal handler race condition, it prevents sshd from being exploitable: the syslog() inside the SIGALRM handler does not call any of the malloc functions, because it is never the very first call to syslog(). No mention on 22.04 yet.

djmdjm 2y ago

Ubuntu isn't affected _by this exploit_

jgalt212 2y ago
as opposed to the other exploits not being discussed.

mmsc 2y ago

>Mitigate by using fail2ban? In theory, this could be used (much quicker than the mentioned days/weeks) to get local privilege escalation to root, if you already have some type of shell on the system already. I would assume that fail2ban doesn't block localhost.

udev4096 2y ago
How is local privilege escalation relevant here? Fail2ban should be able to block the RCE
- mmsc 2y ago
  How is it not? If fail2ban isn't going to blocklist localhost, then it isn't a mitigation for this vulnerability because RCE implies LPE.
  - DEADMINCE 2y ago
    People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to. But, sure, in that case fail2ban won't mitigate, but that's pretty damn obviously implied. For 99% of people and situations, it will.
    - mmsc 2y ago
      >People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to It's going to apply to the amount of servers that an attacker has low-privileged access (think: www-data) and an unpatched sshd. Attackers don't care if it's an RCE or not: if a public sshd exploit can be used on a system with a Linux version without a public Linux LPE, it will be used. Being local also greatly increases the exploitability. Then consider the networks where port 22 is blocked from the internet but sshd is running in some internal network (or just locally for some reason).
      - 2y ago

nubinetwork 2y ago

Ubuntu has pushed an updated openssh.

paulmd 2y ago

> Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). AMD to the rescue - fortunately they decided to leave the take-a-way and prefetch-type-3 vulnerability unpatched, and continue to recommend that the KPTI mitigations be disabled by default due to performance costs. This breaks ASLR on all these systems, so these systems can be exploited in a much shorter time ;) AMD’s handling of these issues is WONTFIX, despite (contrary to their assertion) the latter even providing actual kernel data leakage at a higher rate than meltdown itself… (This one they’ve outright pulled down their security bulletin on) https://pcper.com/2020/03/amd-comments-on-take-a-way-vulnerability/ https://pcper.com/2020/03/amd-comments-on-take-a-way-vulnera... (This one remains unpatched in the third variant with prefetch+TLB) https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1017.html https://www.amd.com/en/resources/product-security/bulletin/a... edit: there is a third now building on the first one with an unpatched vulnerabilities in all zen1/zen2 as well… so this one is WONTFIX too it seems, like most of the defects TU Graz has turned up. https://www.tomshardware.com/news/amd-cachewarp-vulnerability-afflicts-epyc-server-cpus https://www.tomshardware.com/news/amd-cachewarp-vulnerabilit... Seriously I don’t know why the community just tolerates these defenses being known-broken on the most popular brand of CPUs within the enthusiast market, while allowing them to knowingly disable the defense that’s already implemented that would prevent this leakage. Is defense-in-depth not a thing anymore? Nobody in the world would ever tell you to explicitly turn off ASLR on an intel system that is exposed to untrusted attackers… yet that’s exactly the spec AMD continues to recommend and everyone goes along without a peep. It’s literally a kernel option that is already running and tested and hardens you against ASLR leakage. The “it’s only metadata” is so tired. Metadata is more important than regular data, in many cases. We kill people, convict people, control all our security and access control via metadata. Like yeah it’s just your ASLR layouts leaking, what’s the worst that could happen? And I mean real data goes too in several of these exploits too, but that’s not a big deal either… not like those ssh keys are important, right?

JackSlateur 2y ago
What are you talking about ? My early-2022 ryzen 5625U shows: Vulnerabilities: Gather data sampling: Not affected Itlb multihit: Not affected L1tf: Not affected Mds: Not affected Meltdown: Not affected Mmio stale data: Not affected Reg file data sampling: Not affected Retbleed: Not affected Spec rstack overflow: Vulnerable: Safe RET, no microcode Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Spectre v2: Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP always-on; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected Srbds: Not affected Tsx async abort: Not affected Only regular stuff

skeetmtp 2y ago

Ubuntu released patches though https://ubuntu.com/security/notices/USN-6859-1 https://ubuntu.com/security/notices/USN-6859-1

markhahn 2y ago

fail2ban just means an attacker would need to use many source IPs, not hard.