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

81–90 of 118 posts

Re: OpenBSD – pinning all system calls

#81

Post by msm_ »

bheadmaster wrote: post #62
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…

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

>I'm sure OpenBSD developers have very good intuition on what could be used in a vulnerability, without having to write one themselves

Why? On average programmers are not very good security engineers. And the opposite - security engineers are often not a good programmers. If your mitigation doesn't stop any CVE that's being exploited right now in the wild, it's an academic exercise and not particularly useful IMO.

>And fortunately, they don't have a manager above them to whom they need to justify their billing hours.

The point of the thread is that the mitigation cost right now may be low (the "billing hours"), but it's paid in perpetuity by everyone else downstream - in complexity, performance, unexpected bugs, etc. So having a manager or BDFL to evaluate the tradeoffs may be beneficial.

Re: OpenBSD – pinning all system calls

#82

Post by gumby »

monocasa wrote: post #74
gumby wrote: post #73

> in ld.so text, and in that case the main program's text cannot do system calls I don’t understand this case. Is there a way to do IO in openbsd without a system call? Without IO how can you get the result of the computation? Is this a singular special case?

ld.so can do so while initially linking the application in pre main, then in > 4) in libc.so text, and ld.so tells the kernel where that is > The first 3 were cases were configured entirely by the kernel, the 4th case used a new msyscall(2) system call to identify the correct libc.so region. ld.so passes its ability to make syscalls to libc.so. The application has to call into libc.so in order to perform any IO.

Ah, makes sense, thanks. Libc can sanitize all the inputs, and as long as ld.so has a hardwired path to libc all is well. This way you don’t even need a facility to tell the kernel “this binary is allowed to make system calls.

Re: OpenBSD – pinning all system calls

#83

Post by tptacek »

bheadmaster wrote: post #62
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…

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

They famously do not. That's OK, it's a trait shared by a lot of hardening developers on other platforms, too --- all of them are better at this than I'll ever be. But the gulf of practical know-how between OS developers and exploit developers has been for something like 2 decades now a continuing source of comedy. Search Twitter for "trapsled", or "RETGUARD", for instance.

Re: OpenBSD – pinning all system calls

#84

Post by tptacek »

wolverine876 wrote: post #36
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.

"That's from four years ago" is a funny rebuttal to "classic thread".

Re: OpenBSD – pinning all system calls

#85

Post by actionfromafar »

accessvector wrote: post #77
accessvector wrote: post #55

Earlier quoted context omitted.

Out-of-bounds heap write happens in this function: int elf_read_pintable(struct proc *p, Elf_Phdr *pp, struct vnode *vp, Elf_Ehdr *eh, uint **pinp) { struct pinsyscalls { u_int offset; u_int sysno; } *syscalls = NULL; int i, npins = 0, nsyscalls; uint *pins = NULL; [1] nsyscalls = pp->p_filesz / sizeof(*syscalls); if (pp->p_filesz != nsyscalls * sizeof(*syscalls)) goto bad; [2] syscalls = malloc(pp->p_filesz, M_PINSY…

Re-reading this, my analysis is slightly incorrect: the `MAX` at [5] with an unsigned arg means we can make `npins` an arbitrary `int` using the loop at [4]. Choosing to make `npins` negative using that loop means we'll end up allocating an array of 87 (`SYS_kbind + 1`) `int`s at [8] and continue with the OOB accesses described. You'd set up your `pinsyscall` entries like this: struct pinsyscall entries[] = { { .sysn…

I must misunderstand something very basic about this code.

    if (pins[syscalls[i].sysno])
but pins is newly allocated and should just zero or "empty". Why dereference it right after allocation?

Re: OpenBSD – pinning all system calls

#86

Post by accessvector »

actionfromafar wrote: post #85
accessvector wrote: post #77

Earlier quoted context omitted.

Re-reading this, my analysis is slightly incorrect: the `MAX` at [5] with an unsigned arg means we can make `npins` an arbitrary `int` using the loop at [4]. Choosing to make `npins` negative using that loop means we'll end up allocating an array of 87 (`SYS_kbind + 1`) `int`s at [8] and continue with the OOB accesses described. You'd set up your `pinsyscall` entries like this: struct pinsyscall entries[] = { { .sysn…

I must misunderstand something very basic about this code. if (pins[syscalls[i].sysno]) but pins is newly allocated and should just zero or "empty". Why dereference it right after allocation?

Just to handle the case where the same syscall number is specified twice by the ELF header: in that case, the entry is set to -1 (presumably meaning it’s invalid).

Re: OpenBSD – pinning all system calls

#87

Post by jcranmer »

ninjin wrote: post #57
nextaccountic wrote: post #41

Earlier quoted context omitted.

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

Implying that OpenBSD has not considered Rust? There is plenty of discussion on misc@ already (for example [1]) and while it certainly can be "ranty", I am sure if one reads it in good faith you get a fairly nuanced picture. [1]: https://marc.info/?l=openbsd-misc&m=151233210523661&w=2 Look, I think a lot of programmers and managers fail to understand the number of factors one needs to consider and how it scales with…

> I am sure if one reads it in good faith you get a fairly nuanced picture.

I don't see a lot of nuance. The primary argument in that thread boils down to any programmer who isn't using C isn't a serious programmer. The dominant technical analyses are a) adding more compiler toolchains make builds take a lot longer and b) memory safety doesn't protect against everything, so why bother? That's not nuance.

Nuance would be pointing out that Rust provides benefits over just memory safety: that Rust tends to push you towards a parse-don't-validate memory, or maybe Rust having a greater emphasis on error checking correctly [1]. But then again, Rust isn't necessary to do that, so you could also analyze how existing software development practices are sufficient to bring those into play.

You can also discuss Rust's failures. Rust, after all, didn't get uninitialized memory right. There's also some uneasiness about the details of the borrow checker to point to, or you can throw some remarks about the &mut-is-noalias and the difficulty it takes to actually ensure that you never create two &mut to the same location in unsafe code.

Nuance might also discuss how safety features do and don't percolate in mixed-programming-language environments, or how a rewrite may or may not improve security. There's definitely items on both sides of the cost-benefit ledger there!

But that's not what we got. The thread starts with an (incorrect [2]) gatekeeping moment of "it's not serious if you don't rewrite coreutils in it," and mostly devolves into a general theme of "anyone who needs their programming language to provide safety wheels is a terrible programmer who shouldn't be allowed anywhere near systems programming". The irony of that viewpoint coming from an OS well known for its love of just-in-case security precautions is not lost on me.

[1] I was recently writing something parsing diffs, and as part of that, I was making sure that the arithmetic on line numbers didn't overflow. Integer overflow (whether signed or unsigned) is frequently ignored as an error source in most programming languages!

[2] At the time the post was written, people were in fact working on doing a rewrite of this stuff in Rust.

Re: OpenBSD – pinning all system calls

#88

Post by tiffanyh »

petee wrote: post #72
MyMonkeyBalls wrote: post #70

Earlier quoted context omitted.

Yeah even a child like me is better at secure programming than Theo De Raadt

Then report the bug like an adult instead of acting like you found some huge published vulnerability in code that was posted for peer review . Thats why the code is there, so others can identify issues; congrats, you did. People make mistakes in every project. So grow up

Would a code analyzer have detected this bug?

(E.g. Valgrind, Flexelint, cppcheck, clang static analyzer, etc.)

If yes, then why aren't code analyzers used on all OpenBSD code submissions, given their stance on having correct code & security focused.

Re: OpenBSD – pinning all system calls

#89

Post by ninjin »

jcranmer wrote: post #87
ninjin wrote: post #57

Earlier quoted context omitted.

Implying that OpenBSD has not considered Rust? There is plenty of discussion on misc@ already (for example [1]) and while it certainly can be "ranty", I am sure if one reads it in good faith you get a fairly nuanced picture. [1]: https://marc.info/?l=openbsd-misc&m=151233210523661&w=2 Look, I think a lot of programmers and managers fail to understand the number of factors one needs to consider and how it scales with…

> I am sure if one reads it in good faith you get a fairly nuanced picture. I don't see a lot of nuance. The primary argument in that thread boils down to any programmer who isn't using C isn't a serious programmer. The dominant technical analyses are a) adding more compiler toolchains make builds take a lot longer and b) memory safety doesn't protect against everything, so why bother? That's not nuance. Nuance would…

Thank you, that is an interesting response to read, but what I was trying to communicate with that sentence was that if you read that thread and others in good faith you can get a fairly nuanced picture and not that it is one in and of itself. I am certainly not implying that you get a nuanced picture from simply reading a mailing list which I described as being littered with rants in the very same sentence that you quoted parts of.

As for the linked thread itself, I just ignored the "Real Programmers Don't Use Pascal" parts (it gets old really fast) and what I arrived it is largely reflected in what I already wrote in the parent and ancestors.

Re: OpenBSD – pinning all system calls

#90

Post by Conscat »

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

OpenBSD doesn't even have hyperthreading? Why does anyone use this OS? The Linux developers put in a lot of effort to make hyperthreading actually work for their kernel rather than ignoring it.
Post reply on HN