Earlier quoted context omitted.
Which track record exactly? Their slogan is known to be a complete lie
[citation needed]
Here are a lot of citations: https://isopenbsdsecu.re/quotes/
OpenBSD – pinning all system calls
71–80 of 118 posts
Re: OpenBSD – pinning all system calls
#72Earlier quoted context omitted.
> Stonks only go up And the signature totally explains their childish reply, over there and here.
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
Re: OpenBSD – pinning all system calls
#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?
Re: OpenBSD – pinning all system calls
#74> 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.
Re: OpenBSD – pinning all system calls
#75Earlier 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.
[deleted]
Re: OpenBSD – pinning all system calls
#76Re: OpenBSD – pinning all system calls
#77Earlier quoted context omitted.
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_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[] = {
{ .sysno = 0x1111, .offset = 0xdeadbeef }, /* first oob write */
{ .sysno = 0x2222, .offset = 0xf000f000 }, /* second oob write */
{ .sysno = 0xffffffff } /* sets npins to 0xffffffff so we under-allocate */
};
Re: OpenBSD – pinning all system calls
#78Earlier 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…
NSA doesn't care about your emailed vulnerability report. They're not spending their own money when they buy zero-day bug chains in platforms people actually use, and even if they were, those bug chains are so ludicrously cheap relative to their utility that any sigint (or law enforcement, for that matter) organization in the world, from Canada to El Salvador, can cheerfully afford them.
Even if your emailed report was a complete bug chain and not, like, an X-Frame-Options redressing issue, it would be harder, and probably more expensive, for NSA to pick the bug up from email than it would be for them to simply fill out a purchase order from one of their private partners.
As always it is helpful to remember as well that NSA's mission is to secure budget for NSA, full stop.
Re: OpenBSD – pinning all system calls
#79Earlier 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…
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/?ve…
A similar warning could be enabled in GCC using the flag -Wsign-compare.
Re: OpenBSD – pinning all system calls
#80Earlier 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
[flagged]