5 ms·

FatGid: FreeBSD 14.x kernel local privilege escalation

105 points by WhyNotHugo 5mo ago

deleted 5mo ago
[deleted]
socphoenix 5mo ago
Not sure why this is saying it isn’t patched, they released the notice including fix for 14.4 yesterday?
- irishcoffee 5mo ago
  Maybe they're not up to snuff on yesterday? They published this yesterday. > The bug was silently fixed in the main branch on 2025-11-27 (commit 000d5b52c19ff3858a6f0cbb405d47713c4267a4) as a side effect of a broader function refactoring. The fix has not been backported to stable/14 or releng/14.4. FreeBSD 14.4-RELEASE remains vulnerable. > FreeBSD 15.0 still carries the sizeof(*groups) typo and is therefore vulnerable, but the surrounding code differs enough from 14.4 that the chain primitives developed here do not lift the overflow into a working LPE on that branch. On 15.0 the bug remains a kernel panic triggered by any unprivileged user.
turkeyboi 5mo ago
Why does this need to be a whole ass website
- dragontamer 5mo ago
  What? Is there something in this website that feels unnecessary? It seems like a good format of sharing high quality information. This looks like a full bug into a complete root escalation of a kernel. That's hard to do and deserving of praise. The fact that we have a writeup organized like this is awesome. ------- This is sort of the expert level stuff that I thought HackerNews would most enjoy.
- cryo32 5mo ago
  You're not going to get anywhere in the security sector unless you gain notoriety i.e. are noticed. This appears to come from dressing up like Elton John in a feather suit and hiring a marketing team.
  - tptacek 5mo ago
    It's a wall of text about a kernel stack overflow. I'm not sure where the "Elton John" part is. Is it... that they used an accent color?
    - 866-RON-0-FEZ 5mo ago
      Maybe the researcher was wearing windshield-wiper spectacles when he discovered the vulnerability. I don't understand why you're being so defensive about this.
      - tptacek 5mo ago
        Because it's a tiresome, tropey, and ultimately invalid complaint. Look downthread at the person who said the FreeBSD commit log was better than this page, despite being inscrutable to security practitioners who don't work in the kernel and not saying a word about proven exploit vectors. These complaints aren't about what's better or worse for the user community; they're about people trying to put vulnerability researchers in their place.
        866-RON-0-FEZ 5mo ago
        While I believe whimsical names will always be silly, I do concede that commit log is effectively useless to 99% of eyeballs.
        tptacek 5mo ago
        It's not even a complete description of the vulnerability. It's what the kernel maintainers need to know to understand and fix the bug in the code. The claim that it's superior to the branded vulnerability page gives away the whole game.
- tptacek 5mo ago
  Why not? This weird complaint has been happening since ~2010 and it has never made any sense. You are strictly better off with the website than without it. When it was vulnerability researchers getting all peevish about the status competition they were running, I at least understood where the complaint was coming from, but even among practitioners, branded vulnerabilities are so much the norm at this point that there's no status implication anymore.
  - themafia 5mo ago
    > You are strictly better off with the website than without it. Why? This is a better resource in every way: https://cgit.freebsd.org/src/commit/?id=000d5b52c19ff3858a6f0cbb405d47713c4267a4 https://cgit.freebsd.org/src/commit/?id=000d5b52c19ff3858a6f... It details the actual problem instead of showing off tired stack exploit tricks.
    - tptacek 5mo ago
      No, that commit log is obviously not better than the page explaining the vulnerability and the exploit vectors. Case in point: what's "tired" about the stack exploitation techniques they're using here? And, while you're not right, even stipulating that you were, what would that matter? How is anyone better off with less explanation of a vulnerability?
      - themafia 5mo ago
        The website explains an exploit. I've seen exploits before. The commit explains the unique issue. I'm more interested in the why than the how. I suppose people with different overall goals will see that differently.
        tptacek 5mo ago
        You didn't answer my question. What's "tired" about the exploit technique here?
    - tom_ 5mo ago
- rs_rs_rs_rs_rs 5mo ago
  Have you not done anything remotely interesting for you that you want to build a website so the whole world can see it?
- 866-RON-0-FEZ 5mo ago
  It gives legitimacy to whatever whimsical name was given to a vulnerability by registering the domain. CVE numbers are for boring professionals.
  - elkrapo 5mo ago
    The cool kiddies wait and time their disclosures on the cool numbers.
- throwaway613746 5mo ago
  [dead]
djha-skin 5mo ago
TrueNAS is on FreeBSD, as well as lots of network equipment. This does affect us more than we think as operators.
- ActionHank 5mo ago
  Possibly Playstation as well.
  - sbankowi 5mo ago
    Also Netgate's devices running PFSense.
    - anygivnthursday 5mo ago
      And OPNSense boxes
  - loeg 5mo ago
    PlayStation 4 was a fork of FreeBSD 9, and is immune to this bug introduced in 14. Sony also changes a LOT, I'm not sure anything dealing with unix credentials even exists in this fork. It's not clear how much FreeBSD is even used in PlayStation 5 (2020), but it would be based off 12 or earlier (also immune to this bug from 14) (13 was released in 2021).
    - HDBaseT 5mo ago
      What about PlayStation 3? Whilst all are "soft-moddable" via HEN, a large number of the Slim and Superslims are not compatible with full custom firmware. Recently a hardware based exploit 'badWDSD' released which allow CFW, although even still a small number of Superslims are not compatible.
      - loeg 5mo ago
        I thought it went without saying that PS3 (2006) firmware isn't based on FreeBSD 14 (2023).
badgersnake 5mo ago
LPEs are really not impressive enough to warrant names and websites.
CodeCompost 5mo ago
I'm curious to see how many issues an LLM can find for OpenBSD. Not knocking OpenBSD at all, genuinely curious to see if all the careful development can stand up to LLMs.
- keyle 5mo ago
  Someone posted vague screenshots overnight of a bug in exit I think. Waiting on the write up. Edit: ref: https://xcancel.com/ortegaalfredo/status/2057109561702580311 https://xcancel.com/ortegaalfredo/status/2057109561702580311

105 points by WhyNotHugo 5mo ago

deleted 5mo ago

[deleted]

socphoenix 5mo ago

Not sure why this is saying it isn’t patched, they released the notice including fix for 14.4 yesterday?

irishcoffee 5mo ago
Maybe they're not up to snuff on yesterday? They published this yesterday. > The bug was silently fixed in the main branch on 2025-11-27 (commit 000d5b52c19ff3858a6f0cbb405d47713c4267a4) as a side effect of a broader function refactoring. The fix has not been backported to stable/14 or releng/14.4. FreeBSD 14.4-RELEASE remains vulnerable. > FreeBSD 15.0 still carries the sizeof(*groups) typo and is therefore vulnerable, but the surrounding code differs enough from 14.4 that the chain primitives developed here do not lift the overflow into a working LPE on that branch. On 15.0 the bug remains a kernel panic triggered by any unprivileged user.

turkeyboi 5mo ago

Why does this need to be a whole ass website

dragontamer 5mo ago
What? Is there something in this website that feels unnecessary? It seems like a good format of sharing high quality information. This looks like a full bug into a complete root escalation of a kernel. That's hard to do and deserving of praise. The fact that we have a writeup organized like this is awesome. ------- This is sort of the expert level stuff that I thought HackerNews would most enjoy.
cryo32 5mo ago
You're not going to get anywhere in the security sector unless you gain notoriety i.e. are noticed. This appears to come from dressing up like Elton John in a feather suit and hiring a marketing team.
- tptacek 5mo ago
  It's a wall of text about a kernel stack overflow. I'm not sure where the "Elton John" part is. Is it... that they used an accent color?
  - 866-RON-0-FEZ 5mo ago
    Maybe the researcher was wearing windshield-wiper spectacles when he discovered the vulnerability. I don't understand why you're being so defensive about this.
    - tptacek 5mo ago
      Because it's a tiresome, tropey, and ultimately invalid complaint. Look downthread at the person who said the FreeBSD commit log was better than this page, despite being inscrutable to security practitioners who don't work in the kernel and not saying a word about proven exploit vectors. These complaints aren't about what's better or worse for the user community; they're about people trying to put vulnerability researchers in their place.
      - 866-RON-0-FEZ 5mo ago
        While I believe whimsical names will always be silly, I do concede that commit log is effectively useless to 99% of eyeballs.
        tptacek 5mo ago
        It's not even a complete description of the vulnerability. It's what the kernel maintainers need to know to understand and fix the bug in the code. The claim that it's superior to the branded vulnerability page gives away the whole game.
tptacek 5mo ago
Why not? This weird complaint has been happening since ~2010 and it has never made any sense. You are strictly better off with the website than without it. When it was vulnerability researchers getting all peevish about the status competition they were running, I at least understood where the complaint was coming from, but even among practitioners, branded vulnerabilities are so much the norm at this point that there's no status implication anymore.
- themafia 5mo ago
  > You are strictly better off with the website than without it. Why? This is a better resource in every way: https://cgit.freebsd.org/src/commit/?id=000d5b52c19ff3858a6f0cbb405d47713c4267a4 https://cgit.freebsd.org/src/commit/?id=000d5b52c19ff3858a6f... It details the actual problem instead of showing off tired stack exploit tricks.
  - tptacek 5mo ago
    No, that commit log is obviously not better than the page explaining the vulnerability and the exploit vectors. Case in point: what's "tired" about the stack exploitation techniques they're using here? And, while you're not right, even stipulating that you were, what would that matter? How is anyone better off with less explanation of a vulnerability?
    - themafia 5mo ago
      The website explains an exploit. I've seen exploits before. The commit explains the unique issue. I'm more interested in the why than the how. I suppose people with different overall goals will see that differently.
      - tptacek 5mo ago
        You didn't answer my question. What's "tired" about the exploit technique here?
  - tom_ 5mo ago
rs_rs_rs_rs_rs 5mo ago
Have you not done anything remotely interesting for you that you want to build a website so the whole world can see it?
866-RON-0-FEZ 5mo ago
It gives legitimacy to whatever whimsical name was given to a vulnerability by registering the domain. CVE numbers are for boring professionals.
- elkrapo 5mo ago
  The cool kiddies wait and time their disclosures on the cool numbers.
throwaway613746 5mo ago
[dead]

djha-skin 5mo ago

TrueNAS is on FreeBSD, as well as lots of network equipment. This does affect us more than we think as operators.

ActionHank 5mo ago
Possibly Playstation as well.
- sbankowi 5mo ago
  Also Netgate's devices running PFSense.
  - anygivnthursday 5mo ago
    And OPNSense boxes
- loeg 5mo ago
  PlayStation 4 was a fork of FreeBSD 9, and is immune to this bug introduced in 14. Sony also changes a LOT, I'm not sure anything dealing with unix credentials even exists in this fork. It's not clear how much FreeBSD is even used in PlayStation 5 (2020), but it would be based off 12 or earlier (also immune to this bug from 14) (13 was released in 2021).
  - HDBaseT 5mo ago
    What about PlayStation 3? Whilst all are "soft-moddable" via HEN, a large number of the Slim and Superslims are not compatible with full custom firmware. Recently a hardware based exploit 'badWDSD' released which allow CFW, although even still a small number of Superslims are not compatible.
    - loeg 5mo ago
      I thought it went without saying that PS3 (2006) firmware isn't based on FreeBSD 14 (2023).

badgersnake 5mo ago

LPEs are really not impressive enough to warrant names and websites.

CodeCompost 5mo ago

I'm curious to see how many issues an LLM can find for OpenBSD. Not knocking OpenBSD at all, genuinely curious to see if all the careful development can stand up to LLMs.

keyle 5mo ago
Someone posted vague screenshots overnight of a bug in exit I think. Waiting on the write up. Edit: ref: https://xcancel.com/ortegaalfredo/status/2057109561702580311 https://xcancel.com/ortegaalfredo/status/2057109561702580311