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

181–190 of 347 posts

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

#181

Post by DEADMINCE »

infotogivenm wrote: post #154
DEADMINCE wrote: post #150

Earlier quoted context omitted.

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

> 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 for webapps or something else where normal users most who have a windows machine won't have a shell account.

If there's a server where I only have a local account and I'm trying to get root and it's running an ssh server vulnerable to this attack, of course I'd try it. I just don't expect to be in that situation any time soon, if ever.

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

#182

Post by cies »

boxed wrote: post #85
cies wrote: post #74

Earlier quoted context omitted.

I use port knocking to keep my ssh logs clean. I dont think it adds security (I even brag about using it in public). It allows me to read ssh's logs without having to remove all the script kiddie login attempt spam.

Saying you use it publicly doesn't defeat the security it gives though. Unless you publicly say the port knocking sequence. Which would be crazy.

I meant to say: I dont use it for security, I use it for convenience.

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

#183

Post by DEADMINCE »

daneel_w wrote: post #170
DEADMINCE wrote: post #126

Earlier quoted context omitted.

> Would you like to point to one that successfully utilizes a weakness in OpenBSD itself, which is the topic and implied statement of the video, rather than a weakness in some application running under the superuser? I'm sorry, what? What kind of nonsense distinction is this? Are you trying to very disingenuously try and claim only kernel exploits count as attacks against OpenBSD? Why the hell wouldn't a webserver ze…

> I'm sorry, what? What kind of nonsense distinction is this? > Are you trying to very disingenuously try and claim only kernel exploits count as attacks against OpenBSD? Not at all. I clearly underlined that I'm not looking for cases fitting that specific scenario. The only moving of goalposts is entirely on your behalf by very disingenously misrepresenting my question in a poor attempt to try make your answer or wh…

> Not at all. I clearly underlined that I'm not looking for cases fitting that specific scenario

The thing is, we're trying to talk about the security of OpenBSD compared to its competition.

But you're trying to avoid letting anyone do that by saying only an attack against something in the default install you can do with a user account counts, which is absolutely ridiculous.

I'm not moving the goalposts nor am I pretending in any sense. Your approach just doesn't make sense, measure or indicate anything useful or relevant about the security of OpenBSD. I stated so and explained why.

But hey, keep believing whatever you want buddy.

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

#184

Post by SoftTalker »

fullspectrumdev wrote: post #178
bauruine wrote: post #169

Earlier quoted context omitted.

Because nobody has written an sshd in a memory safe language with the same track record of safety as OpenSSH. I personally wouldn't trust a new sshd for a few years at least.

There’s a Rust library that implements most of the protocol, but I’ve not found a “drop in replacement” using said library yet. Might actually make for a fun side project to build a SSH server using that library and see how well it performs.

Does Rust have some invulnerability to race conditions?

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

#185

Post by runjake »

djmdjm wrote: post #13
morsch wrote: post #7

Earlier quoted context omitted.

> Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time.

I'm confident that someone will make a workable exploit against 64-bit systems.

Context here: djmdjm is Daniel Miller, an OpenSSH/OpenBSD developer.

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

#186

Post by _rdvw »

JackSlateur wrote: post #153
paulmd wrote: post #71

Earlier quoted context omitted.

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

KPTI won't be default enabled on Linux on AMD CPUs is the issue here.

Yet it provides valuable separation between kernel and userspace address ranges.

iirc the predecessor to KPTI was made before these hw flaws were announced as a general enhancement to ASLR.

AMD aside, Spectre V2 isn't even default mitigated for userspace across the board, you must specify spectre_v2=on for userspace to be protected.

https://www.kernel.org/doc/html/latest/admin-guide/kernel-pa...

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

#187

Post by _rdvw »

JackSlateur wrote: post #153
paulmd wrote: post #71

Earlier quoted context omitted.

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

Also if you don't have a bios update available for that newer microcode, give my real-ucode package a try: https://github.com/divestedcg/real-ucode

The linux-firmware repo does not provide AMD microcode updates to consumer platforms unlike Intel.

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

#188

Post by acatton »

gruez wrote: post #146
acatton wrote: post #123

Yearly reminder to run your ssh server behind spiped.[1] [2] [3] [1] https://www.tarsnap.com/spiped.html [2] https://news.ycombinator.com/item?id=29483092 [3] https://news.ycombinator.com/item?id=28538750

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 always be on your VPN, otherwise connnect to your VPN manually before running ssh)

* As opposed to wireguard which runs in the kernel, spiped can easily be set-up to run as a user, and be fully hardened by using the correct systemd .service configuration [4]

* The protocol is much more lightweight than TLS (used by stunnel), it's just AES, padded to 1024 bytes with a 32 bit checksum. [5]

* The private key is much easier to set up than stunnel's TLS certificate, "dd if=/dev/urandom count=4 bs=1k of=key" and you're good to go.

[1] https://packages.debian.org/bookworm/spiped

[2] https://www.freshports.org/sysutils/spiped/

[3] https://archlinux.org/packages/extra/x86_64/spiped/

[4] https://ruderich.org/simon/notes/systemd-service-hardening

[5] https://github.com/Tarsnap/spiped/blob/master/DESIGN.md

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

#189

Post by mmsc »

DEADMINCE wrote: post #136
mmsc wrote: post #120

Earlier quoted context omitted.

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

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

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

#190

Post by mmsc »

DEADMINCE wrote: post #181
infotogivenm wrote: post #154

Earlier quoted context omitted.

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

> 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 Groovy scripts to execute arbitrary commands, the firewall doesn't allow connections through port 22, and it's just a "well, I got access, nothing more to see!"?

Post reply on HN