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

OpenBSD – pinning all system calls

marc.info

Post reply on HN
Print view View original

61–70 of 118 posts

Re: OpenBSD – pinning all system calls

#61

Post by piss_n_chips »

trealira wrote: post #34
qzzi wrote: post #17

Earlier quoted context omitted.

I don't know how they define `MAX`, but I'm guessing it's a typical "a>b?a:b". In function `elf_read_pintable` the `npins` is defined as signed int and `sysno` as unsigned int. So this comparison will be unsigned and will allow to set `npins` to any value, even negative: npins = MAX(npins, syscalls[i].sysno) Then `SYS_kbind` seems to be a signed int. So this comparison will be signed and "fix" the negative `npins` to…

> Then `SYS_kbind` seems to be a signed int. So this comparison will be signed and "fix" the negative `npins` to `SYS_kbind`: npins = MAX(npins, SYS_kbind) No, the comparison is unsigned here. They're integers of the same "conversion rank", so the unsigned type wins and the signed integer is interpreted as unsigned. https://en.cppreference.com/w/c/language/conversion I can never remember the integer conversion rules…

This isn't correct, as npins is a signed int and SYS_kbind is just a macro for the integer 86 (as defined in sys/syscall.h). So it will be a signed comparison between the value of npins and 86.

Re: OpenBSD – pinning all system calls

#62

Post by bheadmaster »

vngzs wrote: post #5
tptacek wrote: post #2

Classic thread on this stuff from Halvar Flake: https://twitter.com/halvarflake/status/1156815950873804800 With that in mind, it'd be handy to know which exploit techniques these steps break, and whether those steps are in the current "meta" game for exploit developers. (The specific mitigation here: the kernel formerly locked system call invocation down to the libc.so area of program text in memory; libc.so is big,…

Indeed, in CCC's "systematic evaluation of OpenBSD's mitigations"[0] the presenter explicitly calls out OpenBSD's tendency to present mitigations without specific examples of CVEs it defeats or exploit techniques the mitigations are known to defend against: > Proper mitigations I think stem from proper design and threat modeling. Strong, reality-based statements like "this kills these vulnerabilities," or "this kills…

> Proper mitigations I think stem from proper design and threat modeling. Strong, reality-based statements like "this kills these vulnerabilities," or "this kills this CVE; it delays production of an exploit by one week." And also thorough testing by seasoned exploit writers. Anything else is relying on pure luck, superstition, and wishful thinking.

The comment seems to imply that "proper design and threat modeling" must stem from real-world CVE-s and proofs of concept. That seems to me like "if nobody heard it, the tree didn't fall" kind of thinking.

I'm sure OpenBSD developers have very good intuition on what could be used in a vulnerability, without having to write one themselves. And fortunately, they don't have a manager above them to whom they need to justify their billing hours.

Re: OpenBSD – pinning all system calls

#63

Post by arzig »

masklinn wrote: post #44
pdonis wrote: post #24

Earlier quoted context omitted.

> assuming your programs don't execute other programs. What about language runtimes? They don't execute other programs in the sense of ELF executables (although the programs they interpret might), but they have to support every syscall that's included in the language. So, for example, the Python interpreter would have to include the appropriate code for every syscall that Python byte code could call (in addition to w…

A langage runtime would dispatch to the libc, which is always whitelisted. This is only an issue for the weirdo langage runtimes who’d also refuse to use libc.

cough go cough

Although it is periodically useful to be able to copy a binary to some random Linux server and know it will work.

Re: OpenBSD – pinning all system calls

#64

Post by petee »

ninjin wrote: post #15
tiffanyh wrote: post #11

Earlier quoted context omitted.

Would you mind sharing how and where in the code, specifically. Geniunely curious.

This just went out to tech@: https://marc.info/?l=openbsd-tech&m=170234892604404&w=2

> Stonks only go up

And the signature totally explains their childish reply, over there and here.

Re: OpenBSD – pinning all system calls

#65

Post by 1over137 »

hedora wrote: post #18
ninjin wrote: post #15

Earlier quoted context omitted.

This just went out to tech@: https://marc.info/?l=openbsd-tech&m=170234892604404&w=2

One of the more under-appreciated features of Rust is that it traps on integer overflow / underflow by default. It’s too bad OpenBSD doesn’t have a good Rust story for the core system. (I understand their reasoning, but it’s still too bad.) I wonder how hard it would be to backport the integer behavior to C. (C++ would be easy: Use templates.) Perhaps they could add a compiler directive that causes vanilla integer ov…

>I wonder how hard it would be to backport the integer behavior to C.

Clang and gcc have flags that can make integer overflow trap.

Re: OpenBSD – pinning all system calls

#66

Post by piss_n_chips »

hedora wrote: post #18
ninjin wrote: post #15

Earlier quoted context omitted.

This just went out to tech@: https://marc.info/?l=openbsd-tech&m=170234892604404&w=2

One of the more under-appreciated features of Rust is that it traps on integer overflow / underflow by default. It’s too bad OpenBSD doesn’t have a good Rust story for the core system. (I understand their reasoning, but it’s still too bad.) I wonder how hard it would be to backport the integer behavior to C. (C++ would be easy: Use templates.) Perhaps they could add a compiler directive that causes vanilla integer ov…

There are compiler flags that OpenBSD could be using but aren't, which would have caught this bug without needing to convert the codebase to Rust. Using -Wconversion would have warned on the mismatched signedness of the MAX macro argument (the unsigned integer, sysno) and its result (being assigned to npins, a signed integer). Alternatively, adding -fsanitize=implicit-integer-sign-change, or a UBSan flag that includes this, would detect this at runtime for the actual range of values that end up causing a change of sign.

Though, these would also be triggered by statements like:

    pins[SYS_kbind] = -1;
Due to the pins array being of unsigned int, so all this sort of code would need to be fixed too.

Re: OpenBSD – pinning all system calls

#67

Post by trealira »

piss_n_chips wrote: post #61
trealira wrote: post #34

Earlier quoted context omitted.

> Then `SYS_kbind` seems to be a signed int. So this comparison will be signed and "fix" the negative `npins` to `SYS_kbind`: npins = MAX(npins, SYS_kbind) No, the comparison is unsigned here. They're integers of the same "conversion rank", so the unsigned type wins and the signed integer is interpreted as unsigned. https://en.cppreference.com/w/c/language/conversion I can never remember the integer conversion rules…

This isn't correct, as npins is a signed int and SYS_kbind is just a macro for the integer 86 (as defined in sys/syscall.h). So it will be a signed comparison between the value of npins and 86.

My bad, I thought npins was unsigned.

Re: OpenBSD – pinning all system calls

#68

Post by binkHN »

insanitybit wrote: post #25
zamalek wrote: post #16

Earlier quoted context omitted.

There have been cases where OpenBSD's hypothetical mitigations have worked out well for the project. I recall a relatively recent DNS cache poisoning attack that OpenBSD was novel in pre-emptively mitigating because something (I think it was the port?) was "needlessly" random. If a mitigation has negligible performance impact, and doesn't introduce a new attack vector, I can't imagine why it would be seen as a bad th…

Every mitigation is code and complexity. There is always a cost.

Not for every mitigation. There are plenty of cases where OpenBSD removed code and functionality because of security implications.

Re: OpenBSD – pinning all system calls

#69

Post by masklinn »

arzig wrote: post #63
masklinn wrote: post #44

Earlier quoted context omitted.

A langage runtime would dispatch to the libc, which is always whitelisted. This is only an issue for the weirdo langage runtimes who’d also refuse to use libc.

cough go cough Although it is periodically useful to be able to copy a binary to some random Linux server and know it will work.

Even for go it should actually work as-is: the syscalls should exist statically in the binary, so the loader can enumerate and whitelist them.

What gets blocked is the system constructing the entire thing at runtime, or at least setting the syscall number dynamically.

Re: OpenBSD – pinning all system calls

#70

Post by MyMonkeyBalls »

petee wrote: post #64
ninjin wrote: post #15

Earlier quoted context omitted.

This just went out to tech@: https://marc.info/?l=openbsd-tech&m=170234892604404&w=2

> Stonks only go up And the signature totally explains their childish reply, over there and here.

Yeah even a child like me is better at secure programming than Theo De Raadt
Post reply on HN