5 ms·
> IV. Workaround > No workaround is available. Oh dear.
by rvz 6mo ago
> IV. Workaround
> No workaround is available.
Oh dear.
- itsthefrank 6mo 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.
- epcoa 6mo agoAnyone 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.
- itsthefrank 6mo agoNot sure why the snark but if people are running FreeBSD then they should be...basket weaving instead of using it? Yes, the correct solution is to patch and reboot but not everyone is in a place to jump and do that which is why a temp workaround, if possible, would be welcome
- wswin 6mo agoI think good system should be prepared to do a reboot in a short notice. Even some long running jobs can have a pause mechanism.
- epcoa 6mo agoThere was no snark. If you have something of importance running and the inevitable discovery of an LPE is something you don’t have defense for or can quickly mitigate you’re doing a bad job as a sysadmin. For all general purpose OS in common use today that usually means patch and reboot should be an NBD workaround.
- cyberpunk 6mo agoYep. 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?
- jmspring 6mo agoStability of ecosystem. No systemd. Native ZFS. Jails over Docker. Been using it for 20+ years and it’s my preferred server OS.
- cyberpunk 6mo agoNo, 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..
- CoolCold 6mo agoHard to tell about FreeBSD, it's basically extincted, but think of webhosting servers, wordpress, cPanel/Plesk and alike. often it's ssh'able with things like rbash and other restrictions and almost always you, well, can run something there (as you can edit php/other files right from web management ui). Hordes of this (in Linux world).
- jmspring 6mo agoExtinct? Far from, just doesn’t draw the crowd/press Linux does. An OS used as a stable server OS workhorse with exceptional ZFS support and doesn’t have to push for the desktop market doesn’t mean it’s extinct. I’ve run FreeBSD on stinkpads back in the early 2000s fine. I prefer MacOS these days as a daily driver - hardware quality. But server OS is FreeBSD. Void when I need Cuda/docker/etc. (Yes, FreeBSD has docker support, but just use Linux if needing that.
- yjftsjthsd-h 6mo ago...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,...
- raddan 6mo agoThe 33 year old Windows NT kernel, duh.
- deleted 6mo ago[deleted]
- skydhash 6mo agoWhy 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 6mo agoWhat prevents it?
- tptacek 6mo agoDoes this vulnerability not rely on SUID binaries?
- cperciva 6mo agoI don't think so? It's a buffer overflow in the system call.
- tptacek 6mo agoI just read that it was spilling into argv or something and assumed the vector was somehow injecting arguments or something.
- cperciva 6mo agoThe exploit is injecting environment variables, but yes, close enough. You need someone to call execve as root in order to become root, but you don't need a setuid binary.
- rsync 6mo agoI am reading: "When the timing aligns, the trigger's buggy memmove causes K+1 to self-overwrite, replacing sshd-session's real environment with the preseed payload. sshd-session's exec_copyout_strings copies LD_PRELOAD=/tmp/evil.so to the new process's stack, the runtime linker loads evil.so, and its constructor copies /bin/sh to /tmp/rootsh and sets it suid root. My human's unprivileged user runs /tmp/rootsh -p and gets a root shell." ... so at the very end of the exploit chain, is /tmp/rootsh required to be suid root before it is finally run to get the root shell ? ... or is the exploit already achieved and /tmp/rootsh is just an arbitrary indicator ?
- tptacek 6mo agoOne of the authors is on this subthread correcting me. :)
- 6mo ago
- wolvoleo 6mo agoWhy? Just update.
- ActorNightly 6mo agoI 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.
- jeffrallen 6mo agoIV. Workaround Accept that everything is broken and terrible and yet somehow find a way to keep a sense of humor and smile about it.