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

91–100 of 118 posts

Re: OpenBSD – pinning all system calls

#91

Post by Narishma »

eb0la wrote: post #59
ninjin wrote: post #23

Earlier quoted context omitted.

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…

IMHO the biggest blocker for Rust inside OpenBSD is that the project already has killed C developers and moving (some stuff) to Rust will need time and effort that could be put into other problems. If they had to stabilize some parts, probably the answer would be different.

> IMHO the biggest blocker for Rust inside OpenBSD is that the project already has killed C developers and moving (some stuff) to Rust will need time and effort that could be put into other problems.

I'm all for dropping C in favor of Rust for new projects, but killing C developers is going a bit too far, don't you think?

Re: OpenBSD – pinning all system calls

#92

Post by actionfromafar »

accessvector wrote: post #86
actionfromafar wrote: post #85

Earlier quoted context omitted.

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

I still don't get it. Shouldn't [9] always evaluate to false, and the code be equivalent to:

    pins = mallocarray(npins, sizeof(int), M_PINSYSCALL, M_WAITOK|M_ZERO);
    for (i = 0; i
Edit:

Hang on - npins is already checked in the loop before, and incremented with ++

syscalls[i].sysno can't be larger than what is allocated with:

pins = mallocarray(npins, sizeof(int), M_PINSYSCALL, M_WAITOK|M_ZERO);

So I still can't find the problem

Re: OpenBSD – pinning all system calls

#93

Post by accessvector »

actionfromafar wrote: post #92
accessvector wrote: post #86

Earlier quoted context omitted.

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

I still don't get it. Shouldn't [9] always evaluate to false, and the code be equivalent to: pins = mallocarray(npins, sizeof(int), M_PINSYSCALL, M_WAITOK|M_ZERO); for (i = 0; i Edit: Hang on - npins is already checked in the loop before, and incremented with ++ syscalls[i].sysno can't be larger than what is allocated with: pins = mallocarray(npins, sizeof(int), M_PINSYSCALL, M_WAITOK|M_ZERO); So I still can't find t…

Consider this:

    struct pinsyscall entries[] = {
        { .sysno = 1, .offset = 0x1234 },
        { .sysno = 2, .offset = 0x5678 },
        { .sysno = 1, .offset = 0x9abc }
    };
Now `nsyscalls` will be 3 and `pin` will be an array of 3 ints, initialised to `{ 0, 0, 0 }`.

When we loop through, we'll set:

    1. `pin[syscalls[0].sysno] = 0x1234` => `pin[1] = 0x1234`
    2. `pin[syscalls[1].sysno] = 0x5678` => `pin[2] = 0x5678`
Now when we come to 3, we'll find `pin[syscalls[2].sysno] != 0` since `syscalls[2].sysno == syscalls[0].sysno` - so we set `pin[1] = -1` instead of `0x9abc`.

Re: OpenBSD – pinning all system calls

#94

Post by wolverine876 »

rs_rs_rs_rs_rs wrote: post #54
wolverine876 wrote: post #36

Earlier quoted context omitted.

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

>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. OpenBSD isn't designed from anyone's interests. https://isopenbsdsecu.re/mitigations/

Only if you personally get to define other people's interests. Apparently they disagree!

Re: OpenBSD – pinning all system calls

#95

Post by insanitybit »

binkHN wrote: post #68
insanitybit wrote: post #25

Earlier quoted context omitted.

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.

In this case we got a code exec.

Re: OpenBSD – pinning all system calls

#96

Post by bheadmaster »

msm_ wrote: post #81
bheadmaster wrote: post #62

Earlier quoted context omitted.

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

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

If your only metric of security is "fixed CVEs", then you're rewarding mistakes that were rectified later, and punishing proactive approach to security that actually makes fewer CVEs appear in the first place.

And Theo's reputation and influence on the security is evidence that what he does is more than just "academic exercise". E.g. he created OpenSSH.

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

While that may or may not be the pattern in general, it is not a rule, and especially doesn't apply in OpenBSD development. OpenBSD is widely regarded as one of the cleanest and most robust (free software) codebases ever.

Re: OpenBSD – pinning all system calls

#97

Post by bheadmaster »

tptacek wrote: post #83
bheadmaster wrote: post #62

Earlier quoted context omitted.

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

> 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

Are you implying that OS developers are 2 decades behind exploit developers? If so, is there any proof of that claim, e.g. OpenBSD exploits?

Or are you implying that OS developers are 2 decades ahead of exploit developers? If so, how is that a bad thing?

Re: OpenBSD – pinning all system calls

#98

Post by nextaccountic »

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…

> Implying that OpenBSD has not considered Rust?

No, not at all. OpenBSD may consider Rust all the time and it may still be not the right language for them.

But Rust might be the right language for some greenfield projects (which means, no rewrite), in ways that doesn't apply to a decades-old OS

Re: OpenBSD – pinning all system calls

#99

Post by actionfromafar »

accessvector wrote: post #93
actionfromafar wrote: post #92

Earlier quoted context omitted.

I still don't get it. Shouldn't [9] always evaluate to false, and the code be equivalent to: pins = mallocarray(npins, sizeof(int), M_PINSYSCALL, M_WAITOK|M_ZERO); for (i = 0; i Edit: Hang on - npins is already checked in the loop before, and incremented with ++ syscalls[i].sysno can't be larger than what is allocated with: pins = mallocarray(npins, sizeof(int), M_PINSYSCALL, M_WAITOK|M_ZERO); So I still can't find t…

Consider this: struct pinsyscall entries[] = { { .sysno = 1, .offset = 0x1234 }, { .sysno = 2, .offset = 0x5678 }, { .sysno = 1, .offset = 0x9abc } }; Now `nsyscalls` will be 3 and `pin` will be an array of 3 ints, initialised to `{ 0, 0, 0 }`. When we loop through, we'll set: 1. `pin[syscalls[0].sysno] = 0x1234` => `pin[1] = 0x1234` 2. `pin[syscalls[1].sysno] = 0x5678` => `pin[2] = 0x5678` Now when we come to 3, we'…

Oh, thanks, now I understand why there is an if in the for loop! But I still can't see how pin[] could be accessed out of bounds, since the array is allocated to be large enough to hold the largest value of .sysno occurring in the entries[] array.

Re: OpenBSD – pinning all system calls

#100

Post by tptacek »

bheadmaster wrote: post #97
tptacek wrote: post #83

Earlier quoted context omitted.

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.

> 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 Are you implying that OS developers are 2 decades behind exploit developers? If so, is there any proof of that claim, e.g. OpenBSD exploits? Or are you implying that OS developers are 2 decades ahead of exploit developers? If so, how is that a bad thing?

Neither, I'm saying that for the past 2 decades, the conventional wisdom in the space has been that OS hardening efforts were some significant quantum of time behind exploit developers, but certainly not "2 decades" worth.

It's an aggregate sentiment, right? There are some mitigations that I think legitimately did set back exploit development, but on the whole I think the sentiment has been that OS hardening mitigations have been not just reactive, but reactive to exploit development that is some significant quantum of time behind the current state of the art.

By way of example, I think people made fun of the original OpenBSD system call mitigation stuff described at the beginning of this post. I have no idea what the consensus would be on this new iteration of the idea.

Post reply on HN