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

341–347 of 347 posts

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

#341

Post by fulafel »

FiloSottile wrote: post #20

Interestingly, the RCE fix was "smuggled" in public almost a month ago. When PerSourcePenalties are enabled, sshd(8) will monitor the exit status of its child pre-auth session processes. Through the exit status, it can observe situations where the session did not authenticate as expected. These conditions include when the client repeatedly attempted authentication unsucessfully (possibly indicating an attack against…

Interesting that this comment has remained the topmost one for 2 days despite being incorrect and being corrected in the message right below it. I wonder if people are only reading the first message in the thread and upvoting and then leaving with the wrong impression.

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

#342

Post by FiloSottile »

fulafel wrote: post #341
FiloSottile wrote: post #20

Interestingly, the RCE fix was "smuggled" in public almost a month ago. When PerSourcePenalties are enabled, sshd(8) will monitor the exit status of its child pre-auth session processes. Through the exit status, it can observe situations where the session did not authenticate as expected. These conditions include when the client repeatedly attempted authentication unsucessfully (possibly indicating an attack against…

Interesting that this comment has remained the topmost one for 2 days despite being incorrect and being corrected in the message right below it. I wonder if people are only reading the first message in the thread and upvoting and then leaving with the wrong impression.

It appears you’ve not read past the topmost reply to the topmost comment, and left with the wrong impression.

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

#343

Post by jcul »

SomeoneFromCA wrote: post #320
jcul wrote: post #300

Earlier quoted context omitted.

You could be surprised. For example, recently I wanted to call `gettid()` in a signal handler. Which I guessed was just a simple wrapper around the syscall. However, it seems this can cache the thread ID in thread local storage (can't remember exact details). I switched to making a syscall instead.

Well, this is possible for sure, but not for primitive functions, such as strcmp. It just does not happen in practice.

For functions like strcmp, I think they must be signal safe, to be POSIX compliant.

https://man7.org/linux/man-pages/man7/signal-safety.7.html

If it's on this list I generally trust it is safe.

I guess my point is, that if it's not, even a simple function may appear safe, but could do surprising things.

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

#344

Post by fulafel »

FiloSottile wrote: post #342
fulafel wrote: post #341

Earlier quoted context omitted.

Interesting that this comment has remained the topmost one for 2 days despite being incorrect and being corrected in the message right below it. I wonder if people are only reading the first message in the thread and upvoting and then leaving with the wrong impression.

It appears you’ve not read past the topmost reply to the topmost comment, and left with the wrong impression.

So it seems!

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

#345

Post by aflukasz »

betaby wrote: post #306
aflukasz wrote: post #227

Earlier quoted context omitted.

So this is effectively like ProxyJump, just with the jump node exposed over SSL and backed by HAProxy binary instead of OpenSSH? What benefits do you see? I mean, you still expose some binary that implements authentication and authorization using cryptography. I think that even RBAC scenarios described in the link above should be achievable with OpenSSH, right?

It's not about RBAC at all. Goal is not to expose ssh socket to the Internet! ssh tcp is encapsulated in https packet and ONLY after successful certificate auth by HAProxy.

Right, but now your are exposing HA proxy socket to the Internet. Why is that better?

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

#346

Post by nh2 »

nh2 wrote: post #293
gruez wrote: post #209

Earlier quoted context omitted.

>scp, among other things, runs over ssh. Ironically scp/sftp caused me more bandwidth headaches than wireguard/openvpn. I frequently experienced cases where scp/sftp would get 10% or even less of the transfer speed compared to a plain http(s) connection. Maybe it was due to packet loss, buffer size, or qos/throttling, but I wasn't able to figure out a definitive solution.

In almost all cases, the reason is OpenSSH's silly limitation of buffer sizes [1]. It limits the amount of data that's "in the cable" (which needs to be more if the cable is long). > The default SSH window size was 64 - 128 KB, which worked well for interactive sessions, but was severely limiting for bulk transfer in high bandwidth-delay product situations. > OpenSSH later increased the default SSH window size to 2 M…

I asked my "why not upstream" question here and got a response:

https://github.com/rapier1/hpn-ssh/issues/89#issuecomment-22...

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

#347

Post by nh2 »

djmdjm wrote: post #310
nh2 wrote: post #293

Earlier quoted context omitted.

In almost all cases, the reason is OpenSSH's silly limitation of buffer sizes [1]. It limits the amount of data that's "in the cable" (which needs to be more if the cable is long). > The default SSH window size was 64 - 128 KB, which worked well for interactive sessions, but was severely limiting for bulk transfer in high bandwidth-delay product situations. > OpenSSH later increased the default SSH window size to 2 M…

You can help by testing/reviewing https://github.com/djmdjm/openssh-wip/pull/29/commits/659cbc...

Awesome!
Post reply on HN