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

RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

qualys.com

Post reply on HN
Print view View original

151–160 of 347 posts

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#151

Post by gruez »

jgalt212 wrote: post #110
growse wrote: post #64

Earlier quoted context omitted.

What benefits does port knocking give over and above a simple VPN? They're both additional layers of authentication, except a VPN seems much more rigorous and brings potentially other benefits. In a world where tailscale etc. have made quality VPNs trivial to implement, why would I both with port knocking?

VPNs drop your bandwidth speeds by 50% on average. And if tailscale has to use a relay server, instead of a direct connection, bandwidth will drop by 70-80%.

>VPNs drop your bandwidth speeds by 50% on average

Source? Wireguard can do 1GB/s on decade old processors[1]. Even openvpn can do 258 Mb/s, which realistically can saturate the average home internet connection. Also, if we're talking about SSH connections, why does throughput matter? Why do you need 1 gigabit of bandwidth to transfer a few keystrokes a second?

[1] https://www.wireguard.com/performance/

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#152

Post by qhwudbebd »

singron wrote: post #113
qhwudbebd wrote: post #58

Once I'd finished upgrading my openssh instances (which are linked against musl not glibc) I thought it'd be interesting to have a poke at musl's syslog(3) and see if it allocates too and so is easily exploitable in the same way. But as far as I can see, it doesn't: https://github.com/bminor/musl/blob/master/src/misc/syslog.c Everything there is either on stack or in static variables protected from reentrancy by the…

If you are right about the allocations, then I think the worst it can do is deadlock since the locks aren't recursive. Deadlock in sigalrm could still lead to a DOS since that might prevent it from cleaning up connections.

Yes, true: if the alarm signal arrives right in the middle of another syslog() call, this should deadlock. (Safer that it not deadlocking and accessing the static state in the signal handler of course!)

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#153

Post by JackSlateur »

paulmd wrote: post #71
letters90 wrote: post #14

> 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

> 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…

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

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#154

Post by infotogivenm »

DEADMINCE wrote: post #150
infotogivenm wrote: post #143

Earlier quoted context omitted.

Think “illegitimate” access to www-data. It’s very common on linux pentests to need to privesc from some lower-privileged foothold (like a command injection in an httpd cgi script). Most linux servers run openssh. So yes I would expect this turns out to be a useful privesc in practice.

> Think “illegitimate” access to www-data. I get the point. My point was the example being given is less than 1% of affected cases. > It’s very common on linux pentests to need to privesc from some lower-privileged foothold Sure. Been doing pentests for 20+ years :) > So yes I would expect this turns out to be a useful privesc in practice. Nah.

> Nah

I don’t get it then… Do you never end up having to privesc in your pentests on linux systems? No doubt it depends on customer profile but I would guess personally on at least 25% of engagements in Linux environments I have had to find a local path to root.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#155

Post by devsda »

lupusreal wrote: post #128
poikroequ wrote: post #124

After the xz backdoor a few months ago, I decided to turn off SSH everywhere I don't need it, either by disabling it or uninstalling it entirely. While SSH is quite secure, it's too lucrative a target, so it will always pose a risk.

I now only bind services to wireguard interfaces. The bet is that a compromise in both the service and wireguard at the same time is unlikely (and I have relatively high confidence in wireguard.)

I'm confident in making ssh changes while logged in via ssh.

Compared to ssh, wireguard configs feel too easy to mess up and risk getting locked out if its the only way of accessing the device.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#156

Post by JackSlateur »

megous wrote: post #2

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). MaxStartups default is 10

Default is 100: https://github.com/openssh/openssh-portable/blob/master/serv...

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#157

Post by metadat »

wiredfool wrote: post #53
0x0 wrote: post #4

Patch out for Debian 12; Debian 11 not affected. https://security-tracker.debian.org/tracker/CVE-2024-6387

Looks like Focal (20.04) isn't on an affected version. Jammy (22.04) looks like it is.

What about, uh, 18.04?

Edit: 18.04 Bionic is unaffected, the ssh version is 7.6 which is too old.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#158

Post by [deleted] »

NelsonMinar wrote: post #148

One interesting comment in the OpenSSH release notes > Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improv…

[deleted]

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#159

Post by someplaceguy »

lupusreal wrote: post #128
poikroequ wrote: post #124

After the xz backdoor a few months ago, I decided to turn off SSH everywhere I don't need it, either by disabling it or uninstalling it entirely. While SSH is quite secure, it's too lucrative a target, so it will always pose a risk.

I now only bind services to wireguard interfaces. The bet is that a compromise in both the service and wireguard at the same time is unlikely (and I have relatively high confidence in wireguard.)

> The bet is that a compromise in both the service and wireguard at the same time is unlikely

An RCE in wireguard would be enough -- no need to compromise both.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#160

Post by [deleted] »

TacticalCoder wrote: post #62

And who was notoriously not exploitable? The ones hiding sshd behind port knocks. And fail2ban: would work too. And a restrictive firewall: would help too. I don't use port-knocking but I really just don't get all those saying: "It's security theater" . We had not one but two major OpenSSH "near fiasco" (this RCE and the xz lib thing) that were both rendered unusable for attackers by using port knocking. To me port-k…

[deleted]
Post reply on HN