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

51–60 of 118 posts

Re: OpenBSD – pinning all system calls

#51

Post by bayindirh »

nextaccountic wrote: post #41
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…

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

Rust brings niceties, but this implies no requirement for considering Rust.

Re: OpenBSD – pinning all system calls

#52

Post by saagarjha »

0xDEAFBEAD wrote: post #46
__turbobrew__ wrote: post #40

Earlier quoted context omitted.

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

He’s not wrong, though. Security researchers don’t use PGP when reporting vulnerabilities typically.

Re: OpenBSD – pinning all system calls

#53

Post by saagarjha »

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 meta doesn’t exist because nobody targets OpenBSD because it’s not used. People’s analysis of it is mostly just their educated guess as to how work for other platforms would carry over.

Re: OpenBSD – pinning all system calls

#54

Post by rs_rs_rs_rs_rs »

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.

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

Re: OpenBSD – pinning all system calls

#55

Post by accessvector »

tiffanyh wrote: post #11
MyMonkeyBalls wrote: post #10

This implementation has a trivial buffer overflow, ROFLMAO

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

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_PINSYSCALL, M_WAITOK);
    [3]  if (elf_read_from(p, vp, pp->p_offset, syscalls,
             pp->p_filesz) != 0) {
          goto bad;
         }
        
    [4]  for (i = 0; i
So first of all we calculate the number of syscalls in the pin section [1], allocate some memory for it [2] and read it in [3].

At [4], we want to figure out how big to make our pin array, so we loop over all of the syscall entries and record the largest we've seen so far [5]. (Note: the use of `MAX` here is fine since `sysno` is unsigned -- see near the top of the function).

With the maximum `sysno` found, we then crucially go on to clamp the value to `SYS_kbind` [6] and +1 at [7].

This clamped maximum value is used for the array allocation at [8].

We now loop through the syscall list again, but now take the unclamped `sysno` as the index into the array to read at [9] and write at [10] and [11]. This is essentially the vulnerability right here.

Through heap grooming, there's a good chance you could arrange for a useful structure to be placed within range of the write at [11] -- and `offset` is essentially an arbitrary value you can write. So it looks like it would be relatively easy to exploit.

Re: OpenBSD – pinning all system calls

#56

Post by rfoo »

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…

There is also "soft" mitigations vs "hard" mitigations guideline as described here [1].

It's handy when designing new mitigations when there's no meta game.

[1] https://googleprojectzero.blogspot.com/2023/08/mte-as-implem...

Re: OpenBSD – pinning all system calls

#57

Post by ninjin »

nextaccountic wrote: post #41
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…

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 the complexity of your codebase and what it interacts with. If you want to rewrite your video processing service which you wrote together with five or so contributors and is say 20,000 lines of C++ into Rust, that is one thing. Take a step back and consider the number of users and what you interact with, it all seems rather manageable and you can probably be backwards compatible with respect to your users. In terms of time, maybe a few months? Maybe even six? For a single programmer that now needs to learn proper Rust.

Now, instead consider what an operating system is and the surface with which it interacts. The absolutely metric ton of hardware, the heap of standards, the massive load of hacks that are documented and undocumented, the large amount of users, the number of contributors and their experience, the platforms that you support, all the software that is written for your operating system to make it useful, etc. OpenBSD is famous (infamous?) for being willing to break things to do "the right thing". But they are also famous (infamous, again?) for being very conservative, which I think is understandable given their security focus and (relatively) low amount of manpower. Rust has certainly been considered, but it is far from the only consideration. This is akin to walking into a multi-million dollar company that has a fully functioning service or piece of software that they have been selling for decades and suggest to management that maybe we should start moving it all from C# to Rust next week, while being blissfully unaware of everything else the company is beholden to. Spoiler, it will not work out that way.

Furthermore, it is somewhat tiring that Rust keeps being touted as the final revelation when it comes to writing safer code. Guess what, there were plenty of projects before Rust that introduced safety in various forms (and at various costs) and there will be plenty of projects after Rust that will do the same. Yes, it is an amazing piece of technology, but it is equally plausible that its influence may not end up in it eating the world; rather give birth to something else or bring some of its thinking into other languages. Only time will tell and worse may end up being better yet again.

So to me, what any operating system (security focused or not) should do is to consider their (limited) options given their own goals and situation. Which is something I have seen plenty of evidence that a project of the age of OpenBSD is doing and successfully so.

Personally, I am keeping an eye on Redox and look forward to see what lessons will be learnt from their take of what an operating system can be. But for my servers and desktop I have and continue (for now?) to run a healthy mix of Linux and BSD while getting work done.

Re: OpenBSD – pinning all system calls

#58

Post by SSLy »

IntelMiner wrote: post #48
MyMonkeyBalls wrote: post #38

Earlier quoted context omitted.

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

[citation needed]

> Two remote public holes in the default install, as in “unauthenticated remote code execution”. How many local privilege escalation? How many remote/local denial of service? How many remote code execution in software not present in the non-default install? How many private ones that were never disclosed? Other operating systems didn’t have many unauthenticated RCE either

Re: OpenBSD – pinning all system calls

#59

Post by eb0la »

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…

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.

Re: OpenBSD – pinning all system calls

#60

Post by yakubin »

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…

In this case more important than any runtime overflow/underflow checks is the fact that the compiler will check that comparison operands are of the same type instead of inserting an implicit cast. Instead the programmer is forced to insert an explicit conversion like .try_into().unwrap(), which clearly suggests the possibility of an error. And if the error isn't handled, it will panic.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Post reply on HN