Calif is just killing it these past couple months. Reminder that Calif is Thai Duong's new firm.
You're always super kind to me :)
Everyone's got a list of people they're proud to have worked with, you're on mine.
Local privilege escalation via execve()
61–70 of 116 posts
Re: Local privilege escalation via execve()
#62Earlier quoted context omitted.
I also use a mix. I moved to FreeBSD initially after a rough period w/Linux in the late 90's. Today, my FreeBSD machines are all VMs running on Linux hosts!
Hah I'm your mirror version -- my linux machines are all VMs running on FreeBSD hosts!
Is bhyve working well for you? Maybe I'll try that in my next rev of my home lab.
Re: Local privilege escalation via execve()
#63Earlier 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,...
The 33 year old Windows NT kernel, duh.
Re: Local privilege escalation via execve()
#64Earlier quoted context omitted.
Yep. You should treat any system where non-admins regularly login as basically insecure/owned and rig your architecture appropriately. 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?
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.
Re: Local privilege escalation via execve()
#65 - args->endp - args->begin_argv + consume);
+ args->endp - (args->begin_argv + consume));
I've seen so many mistakes from it, and seen people spend so much pointless and avoidable time deciphering and verifying it, it really doesn't seem worth it (in most code) for the extremely minor character savings.
Re: Local privilege escalation via execve()
#66- 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…
- and + operators have the same precedence. And a similar bug is possible if the operators were the same (both -). So I’m not sure it’s right to blame this on operator precedence or mixed operators. It’s just that, ultimately, the “consume” needs to be subtracted, not added.
Re: Local privilege escalation via execve()
#67- 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…
- and + operators have the same precedence. And a similar bug is possible if the operators were the same (both -). So I’m not sure it’s right to blame this on operator precedence or mixed operators. It’s just that, ultimately, the “consume” needs to be subtracted, not added.
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 follow.
(Associative operators are fine, obviously)
Re: Local privilege escalation via execve()
#68- 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…
- and + operators have the same precedence. And a similar bug is possible if the operators were the same (both -). So I’m not sure it’s right to blame this on operator precedence or mixed operators. It’s just that, ultimately, the “consume” needs to be subtracted, not added.
Didn't you just suffer from the same trap the parent was trying to avoid?
Re: Local privilege escalation via execve()
#69Earlier quoted context omitted.
Local privilege escalation is largely irrelevant on Windows because basically no one uses it in a multi-user system, and application sandboxing is effectively nonexistent.
I get that multiple human users on a same machine is rare nowadays, and that per-app users were never a thing. But windows still has a root and a lower privilege user. You typically need to click on "run as admin" to elevate privileges to, for example, alter system binaries.
Sure, but that's mostly academic: compromise of the user account is game over for any real user. Not actually being Administrator isn't much consolation when the regular user account can extract your cookie jar, record all of your keystrokes and mouse movements, record all desktop video (except for DRM-protected content, heh) etc.
Re: Local privilege escalation via execve()
#70Earlier quoted context omitted.
- and + operators have the same precedence. And a similar bug is possible if the operators were the same (both -). So I’m not sure it’s right to blame this on operator precedence or mixed operators. It’s just that, ultimately, the “consume” needs to be subtracted, not added.
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.