Insane Vulnerability In OpenSSH Discovered

Recorded live on twitch, GET IN

### Article

### My Stream

### Best Way To Support Me
Become a backend engineer. Its my favorite site

This is also the best way to support me is to support yourself becoming a better backend engineer.

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

[pearshaped]

So this is the backdoor that 10x dev was talking about?

[alexanderjordan]

My phone started blowing up last night right as I was about to take a shower. I was sitting there checking our infra butt naked. Jokes on me, the version of OpenSSH on our servers was old enough to not be impacted.

[tato-chip]

this dyslexic man is doing his best to read for us and you're laughing

[SundaraRamanR]

Curious that they mention that the code that fixed this was "accidentally removed" again and again. Knowing what we know about agents introducing backdoors intentionally, how are they so sure that this was an accident? Not saying we should immediately start pointing fingers for sure, but going to the other extreme and emphasizing it was an "accident" without knowing it to be so also seems like a dangerous assumption.

[Lvvn]

Rare case when hacking/it security really looks like it's imagined to be: reading source code for hidden vulnerabilities that can be exploited with incomprehensible dark magic.

[tommybronze]

19:40 - actually the point is that is packet (with a final byte) is very tiny, it doesn't get segmented and then re-assembled at any point over the internet, hence delivering it is way more reliable from timing perspective, than sending a large chunky boy.

[orterves]

0:33 we should -thank- *PAY* OpenSSH devs for their work.

[tommybronze]

29:00 - they send authentication KEY - which is memcopied from packet into the memory for auth checking - this is why it's important to cause sigalarm while it's being checke, because they KEY is the malicious payload that when executed right jumps the execution pointer to "yes this dude is valid and give him shell"

[AntranigVartanian]

I just came here to say that this doesn't affect OpenBSD, the project that created and maintains OpenSSH.

[MikeU]

Malloc internals (and the internal locking mechanisms) are some advanced voodoo. My traumatic encounter with malloc internals:

A few years back I was troubleshooting what we thought was a memory leak. Turned out it wasn't a leak per se; what had happened was that a new "optimization" had been added to glibc's malloc implementation, which attempted to mitigate lock contention by creating new heap arenas whenever two threads collided on a lock. The idea being that threads which did a lot of malloc/free calls would effectively get their own dedicated heap arenas (eventually), thereby minimizing future lock contention.

Problem was, over time this would cause the number of heap arenas to asymptotically approach the number of threads. And since heap arenas were created with a certain minimum size (64MB IIRC), in a long-running application with hundreds of threads you could eventually chew up ridiculous amounts of RAM.

Mitigation involved setting an environment variable to cap the maximum number of heap arenas, and living with the (tiny) performance hit from heap lock contention.

[alexlowe]

6-8 hours sounds long, but if you target the attack to start overnight or on on the weekend, that's incredibly serious.

[IsZomg]

'So we started reading glibc malloc code'

[ElMarcoh]

Just something to note, just checking the package version is not enough to assert the package is vulnerable, debian and ubuntu often backport patches for CVEs from later software versions, so even if you are using a supposed "vulnerable" version, if you check the package notes (and the package per se) you will see a lot of patches, especially in LTS versions.

[nateofthesouth]

I'm a normie corporate guy who manages some websites. This is such a great channel just for late-breaking security news.

Thank you!

[faarao]

Im just a dumb web developer and don't understand any of this

[CaptTerrific]

I'm just thrilled to see so many references to one of my favorite modern ska bands! :D

[xB-ygiw]

Gotta get LowLevelLearning in on this, this stuff is his bread and butter

[Binxalot]

On Unbuntu servers 1 line patch is: pro fix CVE-2024-6387

[carchocolate]

Wonder if something like the delay symptom they spotted in that xz backoor could be used to nail this window more consistently?

Like a minor issue in one oss giving better odds at a basically probabilistic attack on another...

[MikkoRantalainen]

TL;DR: ssh was supposed to use single-threaded but was executed as effectively multi-threaded thanks to SIGALARM being implemented incorrectly (single-threaded program should not cause any non-volatile changes to program state from SIGALARM handler).

Had all of ssh been written as multi-threaded code the SIGALARM handler would have worked as expected because it would have had to use proper locking to access shared memory structures. Of course, that would have been true only if somebody had been able to write *correct* multi-threaded code in C – that is, without any security vulnerabilities. Even Linux kernel fails this every now and then.

Human programmers are not careful enough to write security sensitive code in C except for random happy mistakes.

Update: 41:05 Yes, in other words it's re-entrant bug. Shouldn't happen in single-threaded code in theory but incorrectly written signal handlers can break those assumptions.