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

191–200 of 347 posts

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

#191

Post by SparkyMcUnicorn »

acatton wrote: post #188
gruez wrote: post #146

Earlier quoted context omitted.

What's the advantage of this relatively obscure tool compared to something standard like wireguard or stunnel?

* The tool is not obscure, it's packaged in most distributions.[1][2][3] It was written and maintained by Colin Percival, aka "the tarnsnap guy" or "the guy who invented scrypt". He is the security officer for FreeBSD. * spiped can be used transparently by just putting a "ProxyCommand" in your ssh_config. This means you can connect to a server just by using "ssh", normally. (as opposed to wireguard where you need to…

Wireguard can also run in userspace (e.g. boringtun[0], wireguard-go[1], Tailscale).

[0] https://github.com/cloudflare/boringtun

[1] https://git.zx2c4.com/wireguard-go/about/

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

#192

Post by DEADMINCE »

mmsc wrote: post #189
DEADMINCE wrote: post #136

Earlier quoted context omitted.

> It's going to apply to the amount of servers that an attacker has low-privileged access (think: www-data) and an unpatched sshd. Right, which is almost none. www-data should be set to noshell 99% of the time. > or just locally for some reason). This is all that would be relevant, and this is also very rare.

>www-data should be set to noshell 99% of the time. Huh? execve(2), of course, lets to execute arbitrary files. No need to spawn a tty at all. https://swisskyrepo.github.io/InternalAllTheThings/cheatshee... >This is all that would be relevant, and this is also very rare. Huh? Exploiting an unpatched vulnerability on a server to get access to a user account is.. very rare? That's exactly what lateral movement is about…

Instead of taking the time to reply 'huh' multiple times, you should make sure you read what you're replying to.

For example:

> Huh? Exploiting an unpatched vulnerability on a server to get access to a user account is.. very rare?

The 'this' I refer to is very clearly not what you've decided to map it to here. The 'this' I refer to, if you follow the comment chain, refers to a subset of something you said which was relevant to your point - the rest was not.

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

#193

Post by DEADMINCE »

mmsc wrote: post #190
DEADMINCE wrote: post #181

Earlier quoted context omitted.

> Do you never end up having to privesc in your pentests on linux systems? Of course I do. I'm not saying privsec isn't useful, I'm saying the cases where you will ssh to localhost to get root are very rare. Maybe you test different environment or something, but on most corporate networks I test the linux machines are dev machines just used for compiling/testing and basically have shared passwords, or they're servers…

>I test the linux machines are dev machines just used for compiling/testing and basically have shared passwords, or they're servers for webapps or something else where normal users most who have a windows machine won't have a shell account. And you don't actually pentest the software which those users on the windows machine are using on the Linux systems? So you find a Jenkins server which can be used to execute Groo…

> And you don't actually pentest the software which those users on the windows machine are using on the Linux systems?

You really love your assumptions, huh?

> it's just a "well, I got access, nothing more to see!"?

I said nothing like that, and besides that, if you were not just focused on arguing for the sake of it, you would see MY point was about the infrequency of the situation you were talking about (and even then your original point seemed to be contrarian in nature more than anything).

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

#194

Post by tetha »

rlpb wrote: post #24
CJefferson wrote: post #21

This is a really good find. One thing which (as an independant person, who isn't doing any of the work!) is it often feels like in order to 'win', people are expected to find a full chain which gives them remote access, rather than just finding one issue, and getting it fixed / getting paid for it. It feels to me like finding a single hole should be sufficient -- one memory corruption, one sandbox escape. Maybe at th…

There are many wannabe security researchers who find issues that are definitely not exploitable, and then demand CVE numbers and other forms of recognition or even a bounty. For example, there might be an app that crashes when accepting malformed trusted input, but the nature of the app is that it's never intended to and realistically never will be exposed to an adversary. In most people's eyes, these are simply bugs…

So many "Security Researchers" are just throwing ZAP at websites and dumping the result into the security@ mail, because there might be minor security improvements by setting yet another obscure browser security header for cases that might not even be applicable.

Or there is no real consideration if that's actually an escalation of context. Like, "Oh if I can change these postgres configuration parameters, I can cause a problem", or "Oh if I can change values in this file I can cause huge trouble". Except, modifying that file or that config parameter requires root/supervisor access, so there is no escalation because you have full access already anyhow?

I probably wouldn't have to look at documentation too much to get postgres to load arbitrary code from disk if I have supervisor access to the postgres already. Some COPY into some preload plugin, some COPY / ALTER SYSTEM, some query to crash the node, and off we probably go.

But yeah, I'm frustrated that we were forced to route our security@ domain to support to filter out this nonsense. I wouldn't be surprised if we miss some actually important issue unless demonstrated like this, but it costs too much time otherwise.

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

#195

Post by johnklos »

ale42 wrote: post #32
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

Such an amount of connections should anyway trigger all possible logging & IDS systems, right?

If you have a public facing Internet server, you're probably already running something like blocklistd or fail2ban. They reduce abuse, but they don't do anything to avoid an issue like this except from naive attackers.

More resourceful attackers could automate attempted exploit using a huge botnet, and it'd likely look similar to the background of ssh brute force bots that we already see 24/7/365.

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

#196

Post by chasil »

Ianvdl wrote: post #180
chasil wrote: post #167

Earlier quoted context omitted.

Or RHEL9. $ rpm -q openssh openssh-8.7p1-38.0.1.el9.x86_64

> Statement > The flaw affects RHEL9 as the regression was introduced after the OpenSSH version shipped with RHEL8 was published.

However, we see the -D option on the listening parent:

  $ ps ax | grep sshd | head -1
     1306 ?        Ss     0:01 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
As mentioned elsewhere here, is -D sufficient to avoid exploitation, or is -e necessary as well?

  $ man sshd | sed -n '/ -[De]/,/^$/p'
     -D      When this option is specified, sshd will not
             detach and does not become a daemon.  This
             allows easy monitoring of sshd.

     -e      Write debug logs to standard error instead
             of the system log.
RHEL9 is also 64-bit only, and we see from the notice:

"we have started to work on an amd64 exploit, which is much harder because of the stronger ASLR."

On top of writing the exploit to target 32-bit environments, this also requires a DSA key that implements multiple calls to free().

There is a section on "Rocky Linux 9" near the end of the linked advisory where unsuccessful exploit attempts are discussed.

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

#197

Post by johnklos »

growse wrote: post #64
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…

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?

Are you assuming that VPNs are more secure than ssh?

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

#198

Post by tptacek »

CJefferson wrote: post #21

This is a really good find. One thing which (as an independant person, who isn't doing any of the work!) is it often feels like in order to 'win', people are expected to find a full chain which gives them remote access, rather than just finding one issue, and getting it fixed / getting paid for it. It feels to me like finding a single hole should be sufficient -- one memory corruption, one sandbox escape. Maybe at th…

Buyers pay for outcomes. Vendors do pay for individual links in the chain.

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

#199

Post by jgalt212 »

gruez wrote: post #151
jgalt212 wrote: post #110

Earlier quoted context omitted.

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/

We ran iperf on our multi-cloud and on prem network.

> Also, if we're talking about SSH connections, why does throughput matter?

scp, among other things, runs over ssh.

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

#200

Post by yjftsjthsd-h »

pm215 wrote: post #144
yjftsjthsd-h wrote: post #91

Earlier quoted context omitted.

Hang on, https://www.man7.org/linux/man-pages/man5/sshd_config.5.html says > If the value is 0, there is no time limit. Isn't that worse ?

The bug is a race condition which is triggered by code which runs when the timeout expires and the SIGALRM handler is run. If there is no time limit, then the SIGALRM handler will never run, and the race doesn't happen. (As the advisory notes, you do then have to deal with the DoS which the timeout setting is intended to avoid, where N clients all connect and then never disconnect, and they aren't timed-out and forci…

Thanks for the explanation; I'd skimmed a little too fast and assumed that this was the more traditional "how many attempts can we squeeze in each connection" rather than something at the end. I guess this makes the hardening advice about lowering that time limit kind of unfortunate.
Post reply on HN