Local privilege escalation via execve()

https://www.freebsd.org/security/advisories/FreeBSD-SA-26:13.exec.asc

by Deeg9rie9usi • 2 months ago

225 91 2 months ago

freebsd.org

rvz• 2 months ago

IV. Workaround
No workaround is available.

Oh dear.

itsthefrank3• 2 months ago

V. Solution
Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot the system.

Not everyone can just freebsd-update and reboot, so yes, "Oh dear." is a good response to this.

epcoa2• 2 months ago

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.

skydhash• 2 months ago

Why can't they? Upgrading and rebooting is kinda the standard response for most security issues. So I would expect something like Ansible's playbooks for this exact scenario. You might also have it setup as a staggered rollout.

paulddraper• 2 months ago

What prevents it?

tptacek5• 2 months ago

Does this vulnerability not rely on SUID binaries?

cperciva3• 2 months ago

I don't think so? It's a buffer overflow in the system call.

cryptbe3• 2 months ago

Nope. Try the PoC on macOS:

https://github.com/califio/publications/blob/main/MADBugs/fr...

The script downloads and sets up FreeBSD on QEMU, then runs the exploit.

The exploit is very smart: https://github.com/califio/publications/blob/main/MADBugs/fr.... It basically backdoors sshd.

wolvoleo2• 2 months ago

Why? Just update.

ActorNightly• 2 months ago

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.

jeffrallen2• 2 months ago

IV. Workaround

Accept that everything is broken and terrible and yet somehow find a way to keep a sense of humor and smile about it.

doublerabbit3• 2 months ago

Linux is on their second and FreeBSD is on their first. How many is Windows on?

pjmlp2• 2 months ago

Plenty, Microsoft has security teams whose job is to attack Windows.

Naturally they don't do blog posts about what they find.

hnlmorg• 2 months ago

You talk as if Windows is the only OS that has red teams attacking the system when clearly that isn’t even remotely true.

murderfs2• 2 months ago

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.

dwattttt2• 2 months ago

If you think Linux is on their first or second, I'm not sure how or what you're counting.

doublerabbit3• 2 months ago

I'm not sure how or what you're counting.

The recent two. FailCopy and DirtyFrag and FreeBSD with Execve.

2 - Linux 1 - FreeBSD.

Of course, all OS have had past-time exploits. Three now have made the news.

cyberpunk4• 2 months ago

This is from April 28th, it was patched in 15.0R-p7.

itsthefrank3• 2 months ago

-p8 is the current patch level for 15.0-RELEASE so if people have been keeping on top of patching this is already two reboots in the past.

cryptbe3• 2 months ago

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

j16sdiz• 2 months ago

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.

i-LINK• 2 months ago

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

yunnpp• 2 months ago

They are fixing bugs in open source projects. What are you doing? You're not even tapping that button.

tptacek5• 2 months ago

Calif is just killing it these past couple months. Reminder that Calif is Thai Duong's new firm.

cryptbe3• 2 months ago

You're always super kind to me :)

tptacek5• 2 months ago

Everyone's got a list of people they're proud to have worked with, you're on mine.

wolvoleo2• 2 months ago

Oof that's a pretty big one, I didn't realise but I had already updated anyway.

0xbadcafebee2• 2 months ago

  memmove(args->begin_argv + extend, args->begin_argv + consume,
      args->endp - args->begin_argv + consume);   // ← bug

C code like this is why we can't have nice things. Arithmetic operation in the arguments of a dangerous function call with no explicit bounds check.

sethops1• 2 months ago

"I just don't write bugs"

Yeah.

Groxx6• 2 months ago

    -     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 really doesn't seem worth it (in most code) for the extremely minor character savings.

om2• 2 months ago

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

Groxx6• 2 months ago

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)

genxy• 2 months ago

Didn't you just suffer from the same trap the parent was trying to avoid?

kstrauser• 2 months ago

I think I’d generalize that rule to require parentheses in any situation where adding parentheses could change the interpretation. I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses.

  a - b - c

is order dependent, even if its deterministic and knowable. When I’m scanning the code to look for a pesky bug, I don’t wanna have to take extra seconds to convince myself that it’s doing what I expect. It steals time and my limited attention from more interesting sections of code.

masklinn2• 2 months ago

I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses.

At this point you just require every compound infix expression to be parenthesised, the terseness isn't worth the inconsistency. Especially as, as others have noted, these operations are only associative when working in some classes (notably not necessarily when dealing with floats).

And then you do automatic parens insertion in the LSP, so you write

    a - b - c

and when you save the lsp fixed it up to

    (a - b) - c

riffraff• 2 months ago

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.

adrian_b2• 2 months ago

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.

0xbadcafebee2• 2 months ago

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.

masklinn2• 2 months ago

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.

kibwen• 2 months ago

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

rurban• 2 months ago

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

Groxx6• 2 months ago

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.

bjackman2• 2 months ago

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!

SoftTalker• 2 months ago

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

r_lee• 2 months ago

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.

this is exactly how I think. and it goes for a lot of stuff in general, we have limited bandwidth and wasting it on useless stuff like this has no real purpose.

yet sometimes I see people show off about how they know how to deal with it but I just don't see the point.

oleganza• 2 months ago

Your response was more correct in a professional sense than producing the piece of knowledge you've been asked for. I'd prefer to work with people who value everyone's time and write programs accordingly. If the interviewer was looking for a valuable expert, they were lucky to get you on board.

tetha• 2 months ago

I've also grown somewhat sensitive to duplication, maybe to a painful level. But, the memmove-call from the AI writeup has duplication in there:

    memmove(args->begin_argv + extend,
            args->begin_argv + consume,
            args->endp - args->begin_argv + consume);   // ← bug

If both `args->begin_argv + consume` are supposed to be the same concept and thus the same value, I'd have a variable for it by now. Some people hate it with a passion, but something like this removes the precendence thinking, prevents modification of one and not the other and makes it easier to follow, for me at least:

    retained_tail_begin = args->begin_argv + consume
    memmove(args->begin_argv + extend,
            retained_tail_begin,
            args->endp - retained_tail_begin);

Though at that point one might also encode the entire intent (as far as I understand it) in variables as well:

    space_to_replace_end = args->begin_argv + extend
    retained_tail_begin = args->begin_argv + consume
    memmove(space_to_replace_end,
            retained_tail_begin,
            args->endp - retained_tail_begin);

Sure we can golf the names somewhat, but that code has my head spin a lot less about math and precedence.

Groxx6• 2 months ago

Yeah - sharing a variable there is a pretty strong signal that they are the same concept and can't be allowed to be different, not just "maybe the same value". That's useful to know.

If there's a ton of it in a dense bit of code, 1) it might be too complex, try making it clearer, and 2) it unfortunately makes for a lot of indirection and that can make it harder to follow, which is generally why I see people dislike it. In non-critical code I can kinda agree with inlining it. Pointer arithmetic is imo never non-trivial tho, paranoia is warranted. Especially in a kernel.

dnw• 2 months ago

A CVE for exeCVE()

jeffrallen2• 2 months ago

Puttin' the CVE in execve.

kkyktkrkekk• 2 months ago

Who would have thought.

Local privilege escalation via execve()

Related Stories