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

271–280 of 347 posts

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

#271

Post by lmm »

lilyball wrote: post #240
formerly_proven wrote: post #176

Earlier quoted context omitted.

This isn't the case for OpenSSH but because a lot of environments (essentially all managed runtimes) actually do this transparently for you when you register a signal "handler" it might be that less people are aware that actual signal handlers require a ton of care. On the other hand "you can't even call strcmp in a signal handler or you'll randomly corrupt program state" used to be a favorite among practicing C lawy…

Why can't you call strcmp? I think a general practice of "only call functions that are explicitly blessed as async-signal-safe" is a good idea, which means not calling strcmp as it hasn't been blessed, but surely it doesn't touch any global (or per-thread) state so how can it corrupt program state? Update: according to https://man7.org/linux/man-pages/man7/signal-safety.7.html strcmp() actually is async-signal-safe a…

> surely it doesn't touch any global (or per-thread) state

Not necessarily. An implementation might choose to e.g. use some kind of cache similar to what the JVM does with interned strings, and then a function like strcmp() might behave badly if it happened to run while that cache was halfway through being rebuilt.

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

#272

Post by Sparkyte »

People still use SSH these days?

I kid, but really you probably shouldn't on Production. You should be exporting your logs and everything else. The host or VM bootstrapped golden images with everything as needed.

It is okay to start that way and figure out your enternals but that isn't for Production. Production is a locked down closed environment.

Recomment from another Hacker News post.

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

#273

Post by Dylan16807 »

YoumuChan wrote: post #270
michaelt wrote: post #246

Earlier quoted context omitted.

> "only intended for processing data from trusted sources" is a frankly ridiculous policy for a serialization/deserialization library. Truly, it's a design decision so ridiculous nobody else has made it. Except Python's pickle, Java's serialization, Ruby's Marshal and PHP's unserialize of course. But other than that, nobody!

And Lua's bytecode loader, recently discussed here: https://news.ycombinator.com/item?id=40830005

I know "code is data", but it's a couple orders of magnitude more reasonable to have unsafe bytecode than to have unsafe data deserialization.

If something is supposed to load arbitrary code, not just data, that needs to be super clear at a glance. If it comes across as a data library, but allows takeover, you have a problem. Especially if there isn't a similar data-only function/library.

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

#274

Post by babuskov »

chasil wrote: post #196
Ianvdl wrote: post #180

Earlier quoted context omitted.

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

Speaking of Rocky 9, they suggest to get the new version from the SIG/Security repository:

https://rockylinux.org/news/2024-07-01-rocky-linux-9-cve-202...

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

#275

Post by kccqzy »

growse wrote: post #66
fanf2 wrote: post #35

Earlier quoted context omitted.

Exactly, yes :-) Signal handlers have so many hazards it's vital to keep them as simple as possible.

I'm not overly familiar with the language and tooling ecosystem, but how trivial is this to detect on a static analysis?

Quite easy.

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

#276

Post by bauruine »

cvalka wrote: post #263
hosteur wrote: post #171

Earlier quoted context omitted.

What is the better working alternative?

https://github.com/francoismichel/ssh3?tab=readme-ov-file

>However, we cannot yet endorse its appropriateness for production systems without further peer review. [0]

Not an alternative and won't be for the foreseeable future.

[0]: https://github.com/francoismichel/ssh3?tab=readme-ov-file#-s...

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

#277

Post by Uptrenda »

Anyone else here just totally crap bricks when they see news like this? Like, I wake up and instantly think all my servers are going to be owned and freak out. Though its usually never that bad, sometimes it is. Looks like in this case my debian servers were fine though.

edit: maybe i should add an iptable rule to only allow ssh from my IP.

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

#278

Post by brazzy »

michaelt wrote: post #246
brazzy wrote: post #228

Earlier quoted context omitted.

That sounds... familiar. Are you perchance the maintainer of SnakeYAML? Yes, it is correct to file a CVE of the highest priority against your project, because "only intended for processing data from trusted sources" is a frankly ridiculous policy for a serialization/deserialization library. If it's your toy project that you never expected anyone to use anyway, you don't care about CVEs. If you want to be taken seriou…

> "only intended for processing data from trusted sources" is a frankly ridiculous policy for a serialization/deserialization library. Truly, it's a design decision so ridiculous nobody else has made it. Except Python's pickle, Java's serialization, Ruby's Marshal and PHP's unserialize of course. But other than that, nobody!

Yes, all of those languages made that bad decision back in the 90s and came to regret it. What's ridiculous is refusing to learn from that.

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

#279

Post by JackSlateur »

paulmd wrote: post #243
_rdvw wrote: post #186

Earlier quoted context omitted.

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

> 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. AMD's security bulletin is actually incredibly weaselly and in fact quietly acknowledges KPTI as the reason further mitigation is not necessary, and then goes on to recommend that KPTI remain disabled anyway. https://www.amd.com/en/resources/product-security/bulletin…

But is this not the same thing on intel CPU ? I believe "new" intel CPU are, too, unaffected by meltdown, and so kpti will be disabled there by default.

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

#280

Post by Arnavion »

INTPenis wrote: post #43

Correct me if I'm wrong but it seems like sshd on RHEL-based systems is safe because they never call syslog. They run sshd with the -D option already, logging everything to stdout and stderr, as their systemd already catches this output and sends it to journal for logging. So I don't see anywhere they would be calling syslog, unless sshd does it on its own. At most maybe add OPTIONS=-e into /etc/sysconfig/sshd.

https://news.ycombinator.com/item?id=40849138
Post reply on HN