Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

openwall.com

Post reply on HN
Print view View original

41–50 of 82 posts

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#41

Post by bonzini »

JackSlateur wrote: post #28
gruturo wrote: post #18

Earlier quoted context omitted.

Enterprises don't go for RHEL because it's free software, yay freedom! They go for it because it gives a very stable, solid foundation. They don't want a fragile base layer prone to breaking every day of the week. This involves backporting a lot of stuff (primarily security fixes) because you can't just upgrade any package to its latest version, it will have entirely new dependencies, potentially breaking changes etc…

Compagnies I've worked for that uses redhat do so because they think paying will prevent them from working. As if, sudenly, running a nearly 10y-old code was no longer stupid, because you paid for it.

Of course it is stupid, the question is whether you have an alternative that isn't stupid and respects all the regulation/certification requirements.

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#42

Post by tptacek »

ericpauley wrote: post #37
tptacek wrote: post #35

Earlier quoted context omitted.

I don't think recognition for researchers is the big win for named vulnerabilities. In the places that matter, they can just describe their findings in a short sentence and get all the recognition that matters. The names are mostly for the benefit of users.

Security researchers definitely do the naming gimmick for personal brand purposes. This may not be as obvious when it’s successful, but academic papers routinely name vulnerabilities when there is no real benefit to users.

The whole point of naming vulnerabilities is to establish a vernacular about them, so it's not surprising that academic papers name them. The literature about hardware microarchitectural attacks, for instance, would be fucking inscrutable (even more than it is now) without the names.

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#43

Post by Joker_vD »

ori_b wrote: post #27
Joker_vD wrote: post #15

Earlier quoted context omitted.

> the language layer has no knowledge of signal handlers or what that means Despite the fact that there is explicit runtime support for signal handlers in the language runtime (i.e. libc).

Libc isn't the language runtime. The runtime is '/use/lib/crt*.o', which has no concept at all of signal handling. Libc isn't particularly intrinsic to the language, and outside of some assembly to make syscalls, you can implement an alternative with a completely different interface, purely in C.

I am fairly certain that glibc uses SA_RESTORER in its sigaction wrapper and implements a suitable sigreturn() function which is provided as the sa_restorer argument.

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#44

Post by sqeaky »

bonzini wrote: post #41
JackSlateur wrote: post #28

Earlier quoted context omitted.

Compagnies I've worked for that uses redhat do so because they think paying will prevent them from working. As if, sudenly, running a nearly 10y-old code was no longer stupid, because you paid for it.

Of course it is stupid, the question is whether you have an alternative that isn't stupid and respects all the regulation/certification requirements.

I wish the places I worked made such principled decisions.

Some places did, but not most. In my 2 decades of contracting I have seen plenty of shops with a real fear of upgrading and no plan for modernizing. They are trapped in decades old tech and prefer it that way for no discernible reason. Worse, they often have no recovery plan if there is a problem. There is a huge amount of maintaining the status quo and trying not to make waves.

For some of these projects a team of like dozen devs could recreate the core product in some new tech in less than a year with the right institutional knowledge. But they don't for a myriad of excuses and reasons.

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#45

Post by JackSlateur »

bonzini wrote: post #41
JackSlateur wrote: post #28

Earlier quoted context omitted.

Compagnies I've worked for that uses redhat do so because they think paying will prevent them from working. As if, sudenly, running a nearly 10y-old code was no longer stupid, because you paid for it.

Of course it is stupid, the question is whether you have an alternative that isn't stupid and respects all the regulation/certification requirements.

Said compagnies have no regulations nor certifications requirements.

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#46

Post by bonzini »

sqeaky wrote: post #44
bonzini wrote: post #41

Earlier quoted context omitted.

Of course it is stupid, the question is whether you have an alternative that isn't stupid and respects all the regulation/certification requirements.

I wish the places I worked made such principled decisions. Some places did, but not most. In my 2 decades of contracting I have seen plenty of shops with a real fear of upgrading and no plan for modernizing. They are trapped in decades old tech and prefer it that way for no discernible reason. Worse, they often have no recovery plan if there is a problem. There is a huge amount of maintaining the status quo and tryin…

To be fair, if they couldn't make the decision to use a non-paid distro, would you trust them to be able to manage the updates, the ABI compatibility breakages, and so on once every year or two?

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#47

Post by JackSlateur »

bonzini wrote: post #46
sqeaky wrote: post #44

Earlier quoted context omitted.

I wish the places I worked made such principled decisions. Some places did, but not most. In my 2 decades of contracting I have seen plenty of shops with a real fear of upgrading and no plan for modernizing. They are trapped in decades old tech and prefer it that way for no discernible reason. Worse, they often have no recovery plan if there is a problem. There is a huge amount of maintaining the status quo and tryin…

To be fair, if they couldn't make the decision to use a non-paid distro, would you trust them to be able to manage the updates, the ABI compatibility breakages, and so on once every year or two?

Of course not

But again, paying for the distribution does not free you from the sysadmin duties

Even worse: because of the long "supported" duration, the common mindset is "fire and forget". After all, why would we care ? That stuff will be "supported" for 10 years, we'll be long gone by then. And when you have high turn-over rate, you hit the champion's title : every thing is legacy, nothing is managed, every thing is crap

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#48

Post by immibis »

rlpb wrote: post #22
klysm wrote: post #7

Earlier quoted context omitted.

Debian has a fairly famous one: CVE-2008-0166

In that particular case upstream _was_ consulted and had acked the patch.

Upstream was consulted for a similar change in another location, where the code was actually unnecessary.

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#49

Post by bregma »

fanf2 wrote: post #25
bregma wrote: post #17

Earlier quoted context omitted.

Well, the compiler has no way of knowing if a function will later be a signal handler after linking, or even dynamic loading. There is no portable way to annotate all functions ever written or ever will be written as being async signal safe. Which functions are async signal safe varies with the operating system and runtime (eg. an unsafe function in linux-gnu might be safe in linux-musl or linux-bionic). Other than t…

What I want when writing a signal handler is to be able to say, this function must be async-signal-safe and therefore all the functions it calls must be async-signal-safe. That can be done purely at compile time; I don’t need to worry about linking. The annotation does not need to be portable; if it’s present on one system then other systems still benefit because the code is written to pass the check. The list of asy…

No, any function can call another function from another translation unit (at link time) or load and call a function from another translation unit (at runtime). How will the compiler enforce the propagation of the requirement in those cases?

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#50

Post by immibis »

tptacek wrote: post #42
ericpauley wrote: post #37

Earlier quoted context omitted.

Security researchers definitely do the naming gimmick for personal brand purposes. This may not be as obvious when it’s successful, but academic papers routinely name vulnerabilities when there is no real benefit to users.

The whole point of naming vulnerabilities is to establish a vernacular about them, so it's not surprising that academic papers name them. The literature about hardware microarchitectural attacks, for instance, would be fucking inscrutable (even more than it is now) without the names.

I'd be happy to file all of them under Spectre/MDS, except for the ones that aren't Spectre/MDS, of course. They don't all need unique names. Most of them are all instances of the same pattern: some value is not present in a register when it's needed, and an Intel CPU design continues to execute speculatively with the previous contents of that register instead of inserting a pipeline bubble, leaking the previous contents of that register. Using an inter-core communication buffer, instead of a load data buffer like the last person, I don't think deserves a new name and logo. A new write-up, yes.

Wikipedia puts them all under one page: https://en.wikipedia.org/wiki/Transient_execution_CPU_vulner...

Post reply on HN