> We disclosed this vulnerability to the kernel security team through responsible disclosure.
The patch on the mailing list is visible here.
The patch is dated today. Isn’t responsible disclosure to wait a bit until the security update can work its way into some actual distributions (or heck even a kernel release) and not publish a detailed 0-day for all Linux kernels?
Edit: reading the exploit description more fully:
> On most (or even all) distributions this strategy doesn’t work.
Only impacts vanilla builds using the default config.
> > On most (or even all) distributions this strategy doesn’t work.
> The vulnerability itself does affect major distributions, but we are not publishing a blueprint for how to perform that exploit.
so no it doesn't only affect vanilla builds, the limitation is only for the specific way the vulnerability is exploited in the post, but not the vulnerability itself
> Isn’t responsible disclosure to wait a bit
Yes, but its also based on waiting a bit after reporting it not after it's fixed. People would even say it's irresponsibility to guarantee you wait until it's fixed + some time as history has shown this will reliably lead to some companies not fixing issues.
So the patch date doesn't matter the report date does (which I we do not know as a proper timeline is missing, something which is absent from the disclosure).
EDIT: Also to be clear while it isn't uncommon to extend disclosure deadlines for sever vulnerabilities if there is clear process/work/intend in fixing it this isn't a sever vulnerability. Most distros set /proc/sys/kernel/perf_event_paranoid by default to 2 which means you need privileges to use perf events at all. And some (Android & Debian) even to 3 which per-se disables perf events even for root users (hence why the article says Android and Debian are not affected).
With the caveat that my only familiarity with the interface is reading the manual page, it seems like only some modes of perf_event_open are privileged.
The exploit provided in the article requires PMUs, i.e. hardware events, which are privileged. The PMU itself, at least the Intel one, is full of bugs and can be used to at least DoS the machine, at most take control of it. Letting anyone access the PMU is already a high-trust event, and I take a skeptical read on exploits that require the attacker to own the machine to start.
these days most distros lock down perf_event pretty tightly by default, making it fairly useless unless you have admin access to your machine
this is due to timing attacks you can do with detailed perf info, but also due to the constant stream of bugs found by the perf_fuzzer that took years to fix and it was easier to just lock down by default
> We disclosed this vulnerability to the kernel security team through responsible disclosure. The patch on the mailing list is visible here.
The patch is dated today. Isn’t responsible disclosure to wait a bit until the security update can work its way into some actual distributions (or heck even a kernel release) and not publish a detailed 0-day for all Linux kernels?
Edit: reading the exploit description more fully:
> On most (or even all) distributions this strategy doesn’t work.
Only impacts vanilla builds using the default config.
> > On most (or even all) distributions this strategy doesn’t work.
> The vulnerability itself does affect major distributions, but we are not publishing a blueprint for how to perform that exploit.
so no it doesn't only affect vanilla builds, the limitation is only for the specific way the vulnerability is exploited in the post, but not the vulnerability itself
> Isn’t responsible disclosure to wait a bit
Yes, but its also based on waiting a bit after reporting it not after it's fixed. People would even say it's irresponsibility to guarantee you wait until it's fixed + some time as history has shown this will reliably lead to some companies not fixing issues.
So the patch date doesn't matter the report date does (which I we do not know as a proper timeline is missing, something which is absent from the disclosure).
EDIT: Also to be clear while it isn't uncommon to extend disclosure deadlines for sever vulnerabilities if there is clear process/work/intend in fixing it this isn't a sever vulnerability. Most distros set /proc/sys/kernel/perf_event_paranoid by default to 2 which means you need privileges to use perf events at all. And some (Android & Debian) even to 3 which per-se disables perf events even for root users (hence why the article says Android and Debian are not affected).
The patch is dated September 5th. Meaning it's 12 days old. Still quite recent though, but it's not from today.
The article is from September 5th.
The article wasn't necessarily made visible on its attributed publication date.
It's trivial to check that it was.
https://web.archive.org/web/20240905203257/https://binarygec...
However, higher up in the article:
> The vulnerability itself does affect major distributions
Probably they worked with a Linux security team privately off-list to develop the patch long before the public patch.
perf_event_open is already privileged.
With the caveat that my only familiarity with the interface is reading the manual page, it seems like only some modes of perf_event_open are privileged.
The exploit provided in the article requires PMUs, i.e. hardware events, which are privileged. The PMU itself, at least the Intel one, is full of bugs and can be used to at least DoS the machine, at most take control of it. Letting anyone access the PMU is already a high-trust event, and I take a skeptical read on exploits that require the attacker to own the machine to start.
these days most distros lock down perf_event pretty tightly by default, making it fairly useless unless you have admin access to your machine
this is due to timing attacks you can do with detailed perf info, but also due to the constant stream of bugs found by the perf_fuzzer that took years to fix and it was easier to just lock down by default
[flagged]