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

21–30 of 82 posts

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

#21

Post by account42 »

bregma wrote: post #17
londons_explore wrote: post #4

Couldn't this entire class of bug be solved by annotating signal handlers in the source code and checking at compile time that anything called from a signal handler is async-signal-safe?

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…

> Well, the compiler has no way of knowing if a function will later be a signal handler after linking, or even dynamic loading.

That's why GP suggested annotating them. Typically this would be done via a function attribute.

> There is no portable way to annotate all functions ever written or ever will be written as being async signal safe.

This is not a requirement for such an annotation to exist and to be used by projects that care about security or even just correctness.

> 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).

And libc implementations already annotate many of their functions to tell the compiler how they work. Compilers are also more than happy to assume behavior of standard function matches the C/C++ standards in non-freestanding environmnets.

> Other than those insurmountable problems, yeah, good idea.

All fairly trivial problems that have already been solved many times for similar issues.

I'd like a more general attribute though to declare that a particular funcion is in some abstract domain and then annotations that certain functions may or may not be called in certain domains. This could come useful in cases where you want some functions to only be called from special threads.

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

#22

Post by rlpb »

klysm wrote: post #7
candiddevmike wrote: post #5

The risk you take when you use a distribution that modifies upstream. Debian has had similar issues in the past (maybe not CVEs, but certainly packager-created bugs).

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

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

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

#23

Post by sqeaky »

Joker_vD wrote: post #15
klysm wrote: post #9

Earlier quoted context omitted.

Sounds reasonable, but since the language layer has no knowledge of signal handlers or what that means, it would be a separation of concerns problem. I'm sure you could get clang to do it, but still a tricky thing to design around. Ultimately it's an example of an invariant where it's clear that programmers can't be trusted to uphold it. In this case, the consequences can be very significant.

> 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).

Yep, such is C.

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

#24

Post by dgrunwald »

londons_explore wrote: post #4

Couldn't this entire class of bug be solved by annotating signal handlers in the source code and checking at compile time that anything called from a signal handler is async-signal-safe?

There are some static analysis tools that can check this.

Cert's SIG30 rule page has a list: https://wiki.sei.cmu.edu/confluence/display/c/SIG30-C.+Call+...

Also there's https://clang.llvm.org/extra/clang-tidy/checks/bugprone/sign...

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

#25

Post by fanf2 »

bregma wrote: post #17
londons_explore wrote: post #4

Couldn't this entire class of bug be solved by annotating signal handlers in the source code and checking at compile time that anything called from a signal handler is async-signal-safe?

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 async-signal-safe functions is well documented and quite short, so it would not be much work to add the annotations to the header files. It’s OK if some safe functions are omitted, because signal handlers should be written to do the absolute bare minimum.

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

#26

Post by sqeaky »

qalmakka wrote: post #19
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…

I understand the business logic behind that. The point is, maybe they should consider paying the upstream developers to backport the stuff themselves instead of dabbling with C code they somewhat understand?

C isn't magic, plenty of people understand it and lots of these projects move quite slow. That these things CVEs on ssh are so rare shows how well this process normally works. These past couple of weeks have had 3(?) ssh vulnerabilities? We often go years with one, and not all are a result of packaging some come from upstream.

Any new process needs to not just fix this problem, but also all or at least most of the problems that the existing processes fixes.

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

#27

Post by ori_b »

Joker_vD wrote: post #15
klysm wrote: post #9

Earlier quoted context omitted.

Sounds reasonable, but since the language layer has no knowledge of signal handlers or what that means, it would be a separation of concerns problem. I'm sure you could get clang to do it, but still a tricky thing to design around. Ultimately it's an example of an invariant where it's clear that programmers can't be trusted to uphold it. In this case, the consequences can be very significant.

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

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

#28

Post by JackSlateur »

gruturo wrote: post #18
qalmakka wrote: post #11

This is why I've always disliked Debian and Red Hat. 1. I hate the fact they have the hubris to think they can be smarter than the upstream developers and patch old versions 2. I hate the fact they don't ship vanilla packages, but instead insist on patching things for features that nobody relies on anyway, __because they're not upstream__. Maintainers should stick to downloading tarballs, building them and updating t…

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.

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

#29

Post by formerly_proven »

AndyMcConachie wrote: post #20
stncls wrote: post #14

No vulnerability name, no website, concise description, neutral tone, precise list of affected distros (RHEL + derivatives and some EOL Fedoras) and even mention of unaffected distros (current Fedoras), plain admission that no attempt was made to exploit. What a breath of fresh air! (I am only joking of course. As a recovering academic, I understand that researchers need recognition, and I have no right to throw ston…

The author of the mail is Solar Designer, a bit of a legend AFAIC. He has no need to pump up his brand and he really really knows what he's doing.

Yeah. He created openwall and the oss-security list.

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

#30

Post by [deleted] »

klysm wrote: post #9
londons_explore wrote: post #4

Couldn't this entire class of bug be solved by annotating signal handlers in the source code and checking at compile time that anything called from a signal handler is async-signal-safe?

Sounds reasonable, but since the language layer has no knowledge of signal handlers or what that means, it would be a separation of concerns problem. I'm sure you could get clang to do it, but still a tricky thing to design around. Ultimately it's an example of an invariant where it's clear that programmers can't be trusted to uphold it. In this case, the consequences can be very significant.

[deleted]
Post reply on HN