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

81–90 of 116 posts

Re: Local privilege escalation via execve()

#81

Post by [deleted] »

asveikau wrote: post #58
TZubiri wrote: post #57

Earlier quoted context omitted.

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.

I know that Chrome on Windows tries to lower its privileges to mitigate exploits, and although it's not very popular, the MS Store app platform does try to do full isolation of apps. So actually, per-app separation of users kinda does happen, or is attempted on Windows.

[deleted]

Re: Local privilege escalation via execve()

#82

Post by ActorNightly »

rvz wrote: post #2

> IV. Workaround > No workaround is available. Oh dear.

I really am starting to think that the level of technical understanding on HN is so low that when readers see an exploit like this, they imagine basically the cult classic movie "Hackers" in their heads where some guy hacks into any machine of their choosing.

Re: Local privilege escalation via execve()

#85

Post by rurban »

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…

That's what pony did also. Operator preceding rules are too arcane, such as the need for manual memory management.

Re: Local privilege escalation via execve()

#86

Post by Groxx »

rurban wrote: post #85
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…

That's what pony did also. Operator preceding rules are too arcane, such as the need for manual memory management.

Nice: https://tutorial.ponylang.io/expressions/ops#precedence

Yeah that's pretty much exactly what I do by hand. I should really give Pony a try some time... there's a lot of stuff in it that I like.

Re: Local privilege escalation via execve()

#87

Post by masklinn »

0xbadcafebee wrote: post #78
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…

IIRC several industry and government coding standards don't permit evaluations in arguments to functions, as the compiler can end up doing wonky things, to say nothing of the likely human error. These are the kind of standards we should be adapting into a software building code to avoid security holes like this one.

These standards are that way because older languages (specifically C and C++) have unspecified evaluation orders for arguments, so multiple argument expressions with conflicting side-effects are non-portable.

Here the expressions are pure, OooE has nothing whatsoever to do with the issue.

Re: Local privilege escalation via execve()

#88

Post by bjackman »

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 bug but can you tell us where it was?"

I gave them a hypothesis but I said my "real answer" was that it's not worth our brain cycles to figure it out, you just shouldn't write code that requires knowing operator precedence. It's just such desperately boring information that I can't hold it in my head.

Interviewing such an insufferable smartarse was probably quite annoying but they did give me the job and I do stand by the underlying principle!

Re: Local privilege escalation via execve()

#89

Post by kibwen »

0xbadcafebee wrote: post #78
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…

IIRC several industry and government coding standards don't permit evaluations in arguments to functions, as the compiler can end up doing wonky things, to say nothing of the likely human error. These are the kind of standards we should be adapting into a software building code to avoid security holes like this one.

Or just use a language with a sane (read: defined) argument evaluation order, which is to say, every language that isn't C or C++.

Re: Local privilege escalation via execve()

#90

Post by j16sdiz »

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...

Your bot's blog is above average bot level.

I am sure you have spend lots of time to make your bot works that great.

Post reply on HN