[HN Gopher] Race conditions in Linux Kernel perf events
___________________________________________________________________
Race conditions in Linux Kernel perf events
Author : signa11
Score : 62 points
Date : 2024-09-17 10:19 UTC (12 hours ago)
(HTM) web link (binarygecko.com)
(TXT) w3m dump (binarygecko.com)
| vlovich123 wrote:
| > 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 wrote:
| The patch is dated September 5th. Meaning it's 12 days old.
| Still quite recent though, but it's not from today.
| remram wrote:
| The article is from September 5th.
| derefr wrote:
| The article wasn't necessarily made visible on its
| attributed publication date.
| Arnavion wrote:
| It's trivial to check that it was.
|
| https://web.archive.org/web/20240905203257/https://binary
| gec...
| remram wrote:
| However, higher up in the article:
|
| > The vulnerability itself does affect major distributions
| loeg wrote:
| Probably they worked with a Linux security team privately off-
| list to develop the patch long before the public patch.
| dathinab wrote:
| > > 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).
| jeffbee wrote:
| perf_event_open is already privileged.
| loeg wrote:
| 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 wrote:
| 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
| jeffbee wrote:
| 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.
___________________________________________________________________
(page generated 2024-09-17 23:00 UTC)