Race conditions in Linux Kernel perf events

https://binarygecko.com/race-conditions-in-linux-kernel-perf-events/

by signa11 • 2 years ago

80 12 2 years ago

vlovich123• 2 years ago

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.

Chilinot• 2 years ago

The patch is dated September 5th. Meaning it's 12 days old. Still quite recent though, but it's not from today.

remram2• 2 years ago

The article is from September 5th.

remram2• 2 years ago

However, higher up in the article:

The vulnerability itself does affect major distributions

loeg2• 2 years ago

Probably they worked with a Linux security team privately off-list to develop the patch long before the public patch.

dathinab• 2 years ago

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

jeffbee2• 2 years ago

perf_event_open is already privileged.

loeg2• 2 years ago

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.

deater• 2 years ago

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

jeffbee2• 2 years ago

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.

Race conditions in Linux Kernel perf events

Related Stories