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

41–50 of 347 posts

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

#41

Post by michaelt »

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…

> Maybe at the moment there are just too many little issues, that you need a full end-to-end hack to really convince people to take you seriously, or pay out bounties?

Let me give you a different perspective.

Imagine I make a serialisation/deserialisation library which would be vulnerable if you fed it untrusted data. This is by design, users can serialise and deserialise anything, including lambda functions. My library is only intended for processing data from trusted sources.

To my knowledge, nobody uses my library to process data from untrusted sources. One popular library does use mine to load configuration files, they consider those a trusted data source. And it's not my job to police other people's use of my library anyway.

Is it correct to file a CVE of the highest priority against my project, saying my code has a Remote Code Execution vulnerability?

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

#42

Post by nubinetwork »

nubinetwork wrote: post #19
cperciva wrote: post #10

Earlier quoted context omitted.

This is the sort of bug which pre-announcement coordination is designed for. Anyone who doesn't have patches ready was either forgotten (I've seen a few instances of "I thought you were going to tell them!") or isn't on the ball.

Gentoo announced it at the same time as qualys, but they're currently trying to backport and bump users to a patched version. https://bugs.gentoo.org/935271

Gentoo has pushed the patched version now.

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

#43

Post by INTPenis »

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.

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

#44

Post by stefan_ »

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 don’t value your time, sure? There’s thousands of systems trying to log into publicly accessible SSH servers all the time.

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

#49

Post by XorNot »

stefan_ wrote: post #44
ale42 wrote: post #32

Earlier quoted context omitted.

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

If you don’t value your time, sure? There’s thousands of systems trying to log into publicly accessible SSH servers all the time.

Yeah slow bruteforces are running all over the net all the time. This means there's no reason not to throw this attack into the mix.
Post reply on HN