This implementation has a trivial buffer overflow, ROFLMAO
Would you mind sharing how and where in the code, specifically.
Geniunely curious.
OpenBSD – pinning all system calls
11–20 of 118 posts
Re: OpenBSD – pinning all system calls
#12Without 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…
The other comment on this thread mentions that it also does something else: >disables all the system calls not explicitly invoked by the program text of a static binary This means that if the original library didn't have an execve call in it, you would'nt be able to use it even if with ROP. In short, this seems useful to block attackers from using syscalls that were not originally used by the program and nothing else…
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!)
Re: OpenBSD – pinning all system calls
#13Earlier quoted context omitted.
The other comment on this thread mentions that it also does something else: >disables all the system calls not explicitly invoked by the program text of a static binary This means that if the original library didn't have an execve call in it, you would'nt be able to use it even if with ROP. In short, this seems useful to block attackers from using syscalls that were not originally used by the program and nothing else…
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!)
*Agent Smith voice*
But what use is a fork() if you're unable to exec()?
Re: OpenBSD – pinning all system calls
#14Earlier quoted context omitted.
The other comment on this thread mentions that it also does something else: >disables all the system calls not explicitly invoked by the program text of a static binary This means that if the original library didn't have an execve call in it, you would'nt be able to use it even if with ROP. In short, this seems useful to block attackers from using syscalls that were not originally used by the program and nothing else…
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!)
It is now less normal for programs to run programs on openbsd.
Re: OpenBSD – pinning all system calls
#15This implementation has a trivial buffer overflow, ROFLMAO
Would you mind sharing how and where in the code, specifically. Geniunely curious.
This just went out to tech@:
Re: OpenBSD – pinning all system calls
#16Classic 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,…
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…
There have been cases where OpenBSD's hypothetical mitigations have worked out well for the project. I recall a relatively recent DNS cache poisoning attack that OpenBSD was novel in pre-emptively mitigating because something (I think it was the port?) was "needlessly" random.
If a mitigation has negligible performance impact, and doesn't introduce a new attack vector, I can't imagine why it would be seen as a bad thing.
Re: OpenBSD – pinning all system calls
#17This implementation has a trivial buffer overflow, ROFLMAO
Would you mind sharing how and where in the code, specifically. Geniunely curious.
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)
npins = MAX(npins, SYS_kbind)
pins[syscalls[i].sysno] = syscalls[i].offset
Re: OpenBSD – pinning all system calls
#18Earlier quoted context omitted.
Would you mind sharing how and where in the code, specifically. Geniunely curious.
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 overflow/wraparound to trap, then add annotations or a special library call that supports modulo arithmetic as expected.
Re: OpenBSD – pinning all system calls
#19Earlier 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…
There have been cases where OpenBSD's hypothetical mitigations have worked out well for the project. I recall a relatively recent DNS cache poisoning attack that OpenBSD was novel in pre-emptively mitigating because something (I think it was the port?) was "needlessly" random. If a mitigation has negligible performance impact, and doesn't introduce a new attack vector, I can't imagine why it would be seen as a bad th…
> If a mitigation has negligible performance impact, and doesn't introduce a new attack vector, I can't imagine why it would be seen as a bad thing.
Because it creates confusion about your threat model, which can ultimately weaken your security.
Re: OpenBSD – pinning all system calls
#20This implementation has a trivial buffer overflow, ROFLMAO
Imagine trying to write secure code in C by hand.