Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

mimmutable() for OpenBSD

lwn.net

Post reply on HN
Print view View original

21–30 of 41 posts

Re: mimmutable() for OpenBSD

#21

Post by anthk »

trasz2 wrote: post #19
notaplumber1 wrote: post #15

Earlier quoted context omitted.

> But using it to prevent the introduction of new code is not all that effective, unless you are far more stringent about how you allow processes to allocate executable regions. For example, if you prevent a program from mapping in any new PROT_EXEC pages after it's initialized itself and then mimmutable all its code, then no new code can be introduced, which is a useful property. But you need that extra bit which mi…

Isn’t pledge(2) trivially easy to escape anymore? This used to be one of the differences compared to eg capsicum(2).

pledge(2) aborts.

Re: mimmutable() for OpenBSD

#24

Post by Sirened »

vbezhenar wrote: post #18
10000truths wrote: post #17

Earlier quoted context omitted.

It also means fewer tools in developers' toolboxes. Not being able to make your own system calls directly, or exercise control over your own address space, means that anything that doesn't conform to a C runtime won't run in OpenBSD. Perhaps that's a tradeoff that the OpenBSD developers are willing to make, but even so, these particular "mitigations" do not address the root cause of many security vulnerabilities: fai…

I think that only Linux had some syscall stability. Every other operating system provides libc or other kind of library with stable interface but syscalls are not stable. Yes, technically you can execute those instructions and your software will work on a fixed kernel version, but that's not what people do.

So just ROP to the syscall you want in libc. Instead of targeting the syscall instruction, directly call mmap. System call randomization is a feature designed to discourage legitimate software from hardcoding syscall numbers. It is not meant as an exploit mitigation.

Re: mimmutable() for OpenBSD

#25

Post by Sirened »

notaplumber1 wrote: post #16
Sirened wrote: post #6

>One of those marks executable memory that is empowered to call into the kernel; on OpenBSD systems, only the C library is given that capability. That will prevent hostile code loaded elsewhere from making direct system calls; protecting the rest of a process with mimmutable() will prevent the changing of protections to allow system calls from elsewhere (such changes would be done with msyscall() on OpenBSD). This is…

If you look at the mitigations OpenBSD is doing as attack surface reduction, it means ultimately fewer tools in the attackers toolbox. It seems many of you are missing the forest for the trees.

The question we have to ask ourselves is whether OpenBSDs mitigations are taking away enough attack surface (or in this case, exploitation tools) to make it worth the engineering and user cost.

I'd argue that things like msyscall and mstack don't at all because they cost attackers only a couple of minutes of time once to develop a bypass technique (ie move the stack pointer before a syscall, reuse the authorized syscall instruction) that they can apply everywhere. This greatly contrasts with mitigations like ASLR where each time an attacker wants to bypass the mitigation they are forced to develop a novel, program dependent strategy to leak some information. This is a huge pain and has definitely killed some otherwise exploited bugs because no such leak could be devised.

Re: mimmutable() for OpenBSD

#26

Post by beachhead »

trasz2 wrote: post #19
notaplumber1 wrote: post #15

Earlier quoted context omitted.

> But using it to prevent the introduction of new code is not all that effective, unless you are far more stringent about how you allow processes to allocate executable regions. For example, if you prevent a program from mapping in any new PROT_EXEC pages after it's initialized itself and then mimmutable all its code, then no new code can be introduced, which is a useful property. But you need that extra bit which mi…

Isn’t pledge(2) trivially easy to escape anymore? This used to be one of the differences compared to eg capsicum(2).

is pledge easy to escape? can you give some examples?

Re: mimmutable() for OpenBSD

#27

Post by Sirened »

daneel_w wrote: post #14
Sirened wrote: post #6

>One of those marks executable memory that is empowered to call into the kernel; on OpenBSD systems, only the C library is given that capability. That will prevent hostile code loaded elsewhere from making direct system calls; protecting the rest of a process with mimmutable() will prevent the changing of protections to allow system calls from elsewhere (such changes would be done with msyscall() on OpenBSD). This is…

> "This too is trivially defeated. You simply need to add another stage to your payload in which you copy your ROP payload onto the legitimate stack, pivot, and continue executing." Have you, or someone else as knowledgeable as you, been able to provide a succesful POC doing this? I admit that I haven't gone about looking for results on this topic and method of attack but I would be very interested in reading about i…

Fine, you've nerd sniped me. I'll write a blogpost defeating both mitigations next week :)

Re: mimmutable() for OpenBSD

#29

Post by beachhead »

Sirened wrote: post #27
daneel_w wrote: post #14

Earlier quoted context omitted.

> "This too is trivially defeated. You simply need to add another stage to your payload in which you copy your ROP payload onto the legitimate stack, pivot, and continue executing." Have you, or someone else as knowledgeable as you, been able to provide a succesful POC doing this? I admit that I haven't gone about looking for results on this topic and method of attack but I would be very interested in reading about i…

Fine, you've nerd sniped me. I'll write a blogpost defeating both mitigations next week :)

i really hope you do this because it's super annoying to see all these folks talk about how these mitigations don't work but nobody really _shows_ it.

it's always the same thing whenever openbsd is mentioned.

"these mitigations don't work."

- "okay, please show us that they don't work"

"well, i don't use openbsd"

rinse. repeat.

it would also be nice to see some patches/fixes/suggestions/etc submitted after you've bypassed/defeated/whatever these things sent to the mailing lists. i don't suppose you'd agree to that?

Re: mimmutable() for OpenBSD

#30

Post by Sirened »

beachhead wrote: post #29
Sirened wrote: post #27

Earlier quoted context omitted.

Fine, you've nerd sniped me. I'll write a blogpost defeating both mitigations next week :)

i really hope you do this because it's super annoying to see all these folks talk about how these mitigations don't work but nobody really _shows_ it. it's always the same thing whenever openbsd is mentioned. "these mitigations don't work." - "okay, please show us that they don't work" "well, i don't use openbsd" rinse. repeat. it would also be nice to see some patches/fixes/suggestions/etc submitted after you've byp…

I don't believe these mitigations are fixable, they are based on a fundamental misunderstanding of how people actually write exploits and what attackers are capable of. The issue is that it is extremely hard to try and limit what an attacker can do once they already have code execution in a process. There is a reason why most low level exploit mitigations apply before this point--once they have code execution, it's largely a lost cause to try and protect the integrity of the compromised process. The way we mitigate after code execution is by taking a step up and using things like sandboxing to try and prevent the compromise from impacting the rest of the system.

Also, I don't think it is quite right of you to be miffed that people aren't writing exploit PoCs to prove these mitigations are moot. These mitigations are trivially wrong to anyone who has any experience with exploit development, and being told to "show proof then" is baffling. It's like trying to explain to your uncle that no, vaccines will not make your child autistic, and him demanding proof. Obviously, that's neither how autism or vaccines work and trying to demonstrate that takes significantly more effort than most anyone cares to put in to a random (internet) argument. But, I am a fool who has too much time, so I'll bite.

Post reply on HN