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

41–50 of 118 posts

Re: OpenBSD – pinning all system calls

#41

Post by nextaccountic »

ninjin wrote: post #23
hedora wrote: post #18

Earlier quoted context omitted.

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…

Look, I get as much as the next guy that Rust brings a lot of niceties. But what we are talking about here is a project that clocks in at just over 19,000,000 lines of C (`wc -l $(find src -name '*.c' -or -name '*.h')`), code heritage going back more than 40 years, an explicit commitment to a very rich set of platforms [1], and a very limited amount of manpower compared to projects such as Linux with their insane lev…

This is all true, but this just means that any security focused OS for the next 40 years should consider Rust

Re: OpenBSD – pinning all system calls

#42

Post by nequo »

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

Earlier quoted context omitted.

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

Suppose your hoop probabilities are 25% and that you have two hoops so that the probability of jumping through both is

  25% * 25% = 6.25%.
You can reduce the size of one of the hoops in half, changing the probability to

  25% * 25%/2 = 3.125%
You can also add a third hoop, in which case the probability is

  25% * 25% * 25% = 1.5625%
1.5625% < 3.125%, so adding a third hoop is better than shrinking one of the two existing hoops. Of course, this argument makes important assumptions about the hoop probabilities.

Re: OpenBSD – pinning all system calls

#43

Post by NobodyNada »

woodruffw wrote: post #3

Without a pre-formed opinion: does anybody have an intuition for the security benefits this provides? My first thought is that it’s primarily mitigating cases of attacker-introduced shellcode, which should already be pretty well covered by techniques like W^X. Code reuse techniques (ROP, JOP, etc.) aren’t impacted, right? I would also think this would cause problems for JITed code, although maybe syscalls in JITed co…

> Code reuse techniques (ROP, JOP, etc.) aren’t impacted, right?

One thing to note is that system calls can no longer be made from the program's .text section; only from within libc. This is highly important because of ASLR: in order to ROP into a syscall, an attacker must now know where libc is located in the virtual address space. Before this mitigation, an attacker that only knew the address of the program binary could search for a sequence of bytes within the .text section that happened to decode to a syscall instruction, and use that for ROP (code reuse techniques can often access a lot of unexpected instructions by jumping into the middle of a multibyte instruction, due to x86's complex and variable-length instruction encoding).

Re: OpenBSD – pinning all system calls

#44

Post by masklinn »

pdonis wrote: post #24
woodruffw wrote: post #12

Earlier quoted context omitted.

Sure, assuming your programs don't execute other programs. I don't know much about OpenBSD specifically, but spawning all over the place is the "norm" in terms of "Unix philosophy" program design. (I agree with the point in the adjacent thread: it's hard to know what to make of security mitigations that aren't accompanied by a threat model and attacker profile!)

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

Re: OpenBSD – pinning all system calls

#45

Post by 0xDEAFBEAD »

nequo wrote: post #42
0xDEAFBEAD wrote: post #39

Earlier quoted context omitted.

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?

Suppose your hoop probabilities are 25% and that you have two hoops so that the probability of jumping through both is 25% * 25% = 6.25%. You can reduce the size of one of the hoops in half, changing the probability to 25% * 25%/2 = 3.125% You can also add a third hoop, in which case the probability is 25% * 25% * 25% = 1.5625% 1.5625% < 3.125%, so adding a third hoop is better than shrinking one of the two existing…

Makes sense. Other key questions would be: complexity cost of added hoop (including, possibly, increased attack surface -- the sequence of hoops is just an abstraction that reality may not obey) and also creation difficulty (it could be that improving an existing hoop is significantly quicker than creating a new one).

Re: OpenBSD – pinning all system calls

#46

Post by 0xDEAFBEAD »

__turbobrew__ wrote: post #40
vngzs wrote: post #5

Earlier quoted context omitted.

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.

>they have also mitigated attacks which weren’t even known to exist

Indeed, I'm reminded of some other comments that tptacek made in a recent thread, about how encrypting vulnerability disclosures "just isn't done":

https://news.ycombinator.com/item?id=38563897

https://news.ycombinator.com/item?id=38569179

I'll bet the NSA is very happy about this situation and is doing everything they can to keep the gravy train rolling.

I thought the entire point of being a good security person was that you're able to anticipate and defend against attacks before they become known... Isn't that what "security mindset" is supposed to entail?

Re: OpenBSD – pinning all system calls

#47

Post by starcraft2wol »

MyMonkeyBalls wrote: post #21
lmm wrote: post #20

Earlier quoted context omitted.

Imagine trying to write secure code in C by hand.

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

Yep, they implement kernel level security, rather than obsessing over language.

Re: OpenBSD – pinning all system calls

#49

Post by qzzi »

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…

No.

Re: OpenBSD – pinning all system calls

#50

Post by krab »

nequo wrote: post #42
0xDEAFBEAD wrote: post #39

Earlier quoted context omitted.

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?

Suppose your hoop probabilities are 25% and that you have two hoops so that the probability of jumping through both is 25% * 25% = 6.25%. You can reduce the size of one of the hoops in half, changing the probability to 25% * 25%/2 = 3.125% You can also add a third hoop, in which case the probability is 25% * 25% * 25% = 1.5625% 1.5625% < 3.125%, so adding a third hoop is better than shrinking one of the two existing…

The probabilities aren't independent. The person jumping through the first hoop is probably more able than average. Therefore, any additional hoop - if it doesn't require a completely orthogonal skill - is less selective.
Post reply on HN