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

Local privilege escalation via execve()

freebsd.org

Post reply on HN
Print view View original

91–100 of 116 posts

Re: Local privilege escalation via execve()

#91

Post by adrian_b »

riffraff wrote: post #77
Groxx wrote: post #65

- args->endp - args->begin_argv + consume); + args->endp - (args->begin_argv + consume)); tbh I've considered simply banning math-operator-precedence in projects I work on, and requiring all mixed-operator code to use parenthesis or split to multiple statements. I do that myself, at least. I've seen so many mistakes from it, and seen people spend so much pointless and avoidable time deciphering and verifying it, it r…

Smalltalk didn't have math operator precedence, and I thought it was very annoying but I've come to believe it was a good idea.

A much older language that does not have operator precedence is APL.

This is the right choice for a language with a great number of operators.

In C they have tried to minimize the number of parentheses in expressions, but for this they have created far too many levels of precedence between operators, which had the opposite effect to that intended, since people now prefer to insert superfluous parentheses, to avoid having to remember all those levels of precedence.

Re: Local privilege escalation via execve()

#92

Post by adrian_b »

tick_tock_tick wrote: post #64
jmspring wrote: post #17

Earlier quoted context omitted.

Stability of ecosystem. No systemd. Native ZFS. Jails over Docker. Been using it for 20+ years and it’s my preferred server OS.

Free root for anyone for over 20 years too.

Nope.

The bug appears to have been introduced in some FreeBSD 13 version.

I run FreeBSD servers that do not have this bug. In my "kern_exec.c" there is no "consume" anywhere. There is also no "memmove" at all.

That file was last patched in 2024, but whatever changes had introduced that bug, they were not back-ported to older FreeBSD versions, so those are not affected.

Re: Local privilege escalation via execve()

#93

Post by chuckadams »

simonreiff wrote: post #70
Groxx wrote: post #67

Earlier quoted context omitted.

Non-mixed always goes strictly left to right, regardless of the operator, which I haven't seen anywhere near as much struggling with. But yes, I personally parenthesize `a-b-c` explicitly, because it's not worth it for me to read and wonder if parenthesizing order matters later. Costs less than a second to write, saves a second or ten each time I read it - that's an excellent tradeoff imo, and is a trivial pattern to…

I agree with explicit parentheses but please be careful about assuming associativity! The risk when handling floating-point arithmetic in particular is that associativity breaks, and suddenly a + (b + c) does NOT equal (a + b) + c. Not only can these lead to unexpected and hard-to-trace failure patterns, but depending on the details, they also can introduce memory overflow/underflow vulnerabilities.

If you're going for bit-for-bit equivalence of float values, then even with a single operation you're relying on compiler flags, architecture, the phase of the moon... I'm hard-pressed to think of any memory safety issues though.

Re: Local privilege escalation via execve()

#94

Post by [deleted] »

yjftsjthsd-h wrote: post #37
epcoa wrote: post #4

Earlier quoted context omitted.

Anyone relying on a 30+ year old monolith kernel written in C to not have some exploitable LPEs lurking should stay in basket weaving and out of sysadmin.

...as opposed to what, exactly? Linux is a 34 y.o. monolithic kernel in C, the BSDs are all forked from the same base (386BSD) of around the same age, XNU is 29 years old (and also heavily based on BSD code while also throwing in mach code) in C and other languages,...

[deleted]

Re: Local privilege escalation via execve()

#96

Post by KAMSPioneer »

cyberpunk wrote: post #20
jmspring wrote: post #17

Earlier quoted context omitted.

Stability of ecosystem. No systemd. Native ZFS. Jails over Docker. Been using it for 20+ years and it’s my preferred server OS.

No, I mean do you run FreeBSD boxes where users who should not ever assume root access actually login to do tasks? My point is that if you do, you probably shouldn't run, for e.g applications which need production db credential, or hold sensitive data on these boxes, or .. whatever. Edit: I use FreeBSD extensively, for various things -- but shell access to them is restricted to the sysadmins..

I mean, where I work we offer machines to external users where they have shell access to be able to do their science, but I don't want them to have root access. Other institutes we work with (like supercomputer networks, etc) give us/users non-root access.

When things like CVE-2026-31431 or the bug that this thread is about affect our systems it causes a big headache. Yeah, we firewall off what we _can_ by having different machines doing critical things versus the ones where science users have code execution, but we don't have the resources to give every user their own machine.

Re: Local privilege escalation via execve()

#97

Post by i-LINK »

cryptbe wrote: post #28

Nice to randomly encounter our own work here. Check out our blog post for a fun walkthrough: https://blog.calif.io/p/cve-2026-7270-how-i-get-root-on-free... AI-generated working exploit, write-up and prompts: https://github.com/califio/publications/tree/main/MADBugs/fr...

"our" is a stretch. Not only because you're giving an algorithm personhood, but because you didn't do any of the real work. So you could instead say that it's "nice to randomly encounter what I prompted an instance of [brand of artificially intelligent dowsing rod] to do". There's your chance to claim ownership; you can plainly state that you're the person who pressed the button.

Re: Local privilege escalation via execve()

#98

Post by SoftTalker »

bjackman wrote: post #88
Groxx wrote: post #65

- args->endp - args->begin_argv + consume); + args->endp - (args->begin_argv + consume)); tbh I've considered simply banning math-operator-precedence in projects I work on, and requiring all mixed-operator code to use parenthesis or split to multiple statements. I do that myself, at least. I've seen so many mistakes from it, and seen people spend so much pointless and avoidable time deciphering and verifying it, it r…

I once had a job interview where they wanted to evaluate my C knowledge. They showed me a printout of some pointer arithmetic and said spot the bug. (It may actually have been the old puzzle where it turns out that /* is always a comment opener and never a division by the referent of a pointer). I said "well first, this is a mess, I'm putting parentheses here, here, here and here". They said "well you've fixed the bu…

I've never had to write or read code in an interview. I wonder how common that is?

Re: Local privilege escalation via execve()

#99

Post by jmspring »

cyberpunk wrote: post #20
jmspring wrote: post #17

Earlier quoted context omitted.

Stability of ecosystem. No systemd. Native ZFS. Jails over Docker. Been using it for 20+ years and it’s my preferred server OS.

No, I mean do you run FreeBSD boxes where users who should not ever assume root access actually login to do tasks? My point is that if you do, you probably shouldn't run, for e.g applications which need production db credential, or hold sensitive data on these boxes, or .. whatever. Edit: I use FreeBSD extensively, for various things -- but shell access to them is restricted to the sysadmins..

No. And hosting providers I have used usually use VM isolation (QEMU/etc) for the VPS type instances they allocate to users. The VM is vulnerable if it happens to have a kernel compiled such that allows this vuln.

Re: Local privilege escalation via execve()

#100

Post by jmspring »

cyberpunk wrote: post #20
jmspring wrote: post #17

Earlier quoted context omitted.

Stability of ecosystem. No systemd. Native ZFS. Jails over Docker. Been using it for 20+ years and it’s my preferred server OS.

No, I mean do you run FreeBSD boxes where users who should not ever assume root access actually login to do tasks? My point is that if you do, you probably shouldn't run, for e.g applications which need production db credential, or hold sensitive data on these boxes, or .. whatever. Edit: I use FreeBSD extensively, for various things -- but shell access to them is restricted to the sysadmins..

Also statements like this one - TBH -- I don't have any of these kinds of boxes anymore. Who is really running anything like this in 2026 and for what purpose?

Does not convey what your clarification attemps to state.

Post reply on HN