Live data from Hacker News

Local privilege escalation via execve()

freebsd.org

11–20 of 116 posts

Re: Local privilege escalation via execve()

#11
post #4

Earlier quoted context omitted.

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

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.

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?

Re: Local privilege escalation via execve()

#13
post #7

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

Plenty, Microsoft has security teams whose job is to attack Windows. Naturally they don't do blog posts about what they find.

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

Re: Local privilege escalation via execve()

#16

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

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

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

Re: Local privilege escalation via execve()

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

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.

Re: Local privilege escalation via execve()

#20

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

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

Post reply on HN