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

31–40 of 118 posts

Re: OpenBSD – pinning all system calls

#31

Post by trealira »

LukeShu wrote: post #30
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…

> I don't know how they define `MAX`, but I'm guessing it's a typical "a>b?a:b" Indeed: https://github.com/openbsd/src/blob/master/sys/sys/param.h#L... > Then `SYS_kbind` seems to be a signed int. It's an untyped #define: https://github.com/openbsd/src/blob/master/sys/sys/syscall.h... I believe your whole analysis is correct, that running an elf file with an openbsd.syscalls entry with .sysno > INT_MAX will allow an…

> It's an untyped #define

Pure decimal integer literals (like 86) are typed as "int" in C, rather than being typeless and triggering type inference. This is a pain when you accidentally write something like this:

  uint64_t n = 1
On modern desktop platforms, an int is 32 bits, so 1 Regardless, it's not relevant here, because if an integer and an unsigned integer of the same size are compared the integer is implicitly cast to unsigned integer, and 86 is fine for both signed and unsigned integers (so "MAX(npins, SYS_kbind)" is safe).

Re: OpenBSD – pinning all system calls

#33

Post by dtx1 »

0xDEAFBEAD wrote: post #28
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,…

Is there a current meta for OpenBSD exploit developers? What's the right way to go about hardening the system if there's no meta to observe? My very naive take would be something like: A successful exploit depends on jumping through a number of different hoops. Each of those hoops has an estimated success probability associated with it. We can multiply all the individual probabilities together to get an estimated pro…

> The most efficient way to harden against exploits is to try and shrink whichever hoop possesses the greatest partial derivative of overall exploit success probability with respect to developer time.

Depending on your definition of efficient, adding more hoops should work exponentially better.

Re: OpenBSD – pinning all system calls

#34

Post by trealira »

qzzi wrote: post #17
tiffanyh wrote: post #11

Earlier quoted context omitted.

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

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 and end up looking up this link whenever necessary.

Re: OpenBSD – pinning all system calls

#35

Post by trealira »

MyMonkeyBalls wrote: post #10

This implementation has a trivial buffer overflow, ROFLMAO

Have you managed to trigger this? You never ended up explaining how the heap overflow occurs, and I cannot determine whether the other person who was guessing how it might happen is right, because I am not very familiar with OpenBSD's code.

Re: OpenBSD – pinning all system calls

#36

Post by wolverine876 »

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,…

> Classic thread on this stuff from Halvar Flake:

That's from four years ago and does not address these technical issues. Are you going to pull it out every time OpenBSD is mentioned? I think people understand that you don't like their approach, etc., and the flaws you see, and that OpenBSD isn't designed for your interests.

Re: OpenBSD – pinning all system calls

#38

Post by MyMonkeyBalls »

gkbrk wrote: post #27
MyMonkeyBalls wrote: post #21

Earlier quoted context omitted.

Yeah and imagine advertising yourself as the "most secure OS in the world" at the same time

Anyone else with their track record?

Which track record exactly? Their slogan is known to be a complete lie

Re: OpenBSD – pinning all system calls

#39

Post by 0xDEAFBEAD »

dtx1 wrote: post #33
0xDEAFBEAD wrote: post #28

Earlier quoted context omitted.

Is there a current meta for OpenBSD exploit developers? What's the right way to go about hardening the system if there's no meta to observe? My very naive take would be something like: A successful exploit depends on jumping through a number of different hoops. Each of those hoops has an estimated success probability associated with it. We can multiply all the individual probabilities together to get an estimated pro…

> The most efficient way to harden against exploits is to try and shrink whichever hoop possesses the greatest partial derivative of overall exploit success probability with respect to developer time. Depending on your definition of efficient, adding more hoops should work exponentially better.

My definition of efficient is essentially whatever decreases the number of workable exploits most rapidly per hour of developer time.

>Depending on your definition of efficient, adding more hoops should work exponentially better.

Explain?

Re: OpenBSD – pinning all system calls

#40

Post by __turbobrew__ »

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…

OpenBSD disabled hyperthreading before speculative execution attacks were in the wild. In the words of Greg K-H “OpenBSD was right”.

There probably is some amount of security theatre in OpenBSD but they have also mitigated attacks which weren’t even known to exist.

Post reply on HN