4 ms·

In case anyone was confused like me, this appears to be describing a past bug from ~10 months ago, not an open one. (the blog post links to the bug also) https:

In case anyone was confused like me, this appears to be describing a past bug from ~10 months ago, not an open one. (the blog post links to the bug also) https://bugs.chromium.org/p/project-zero/issues/detail?id=2125 https://bugs.chromium.org/p/project-zero/issues/detail?id=21...

Datagenerator 5y ago
Thank you, security officer on duty goes back to sleep.
perihelions 5y ago
Did Debian-stable not release the patch until February 2021, or did am I confused? https://lists.debian.org/debian-security-announce/2021/msg00024.html https://lists.debian.org/debian-security-announce/2021/msg00... https://tracker.debian.org/news/1226431/accepted-linux-419171-2-source-into-stable-embargoed-stable/ https://tracker.debian.org/news/1226431/accepted-linux-41917...
- geofft 5y ago
  The commit messages are pretty unclear about whether there's any security impact: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8bcd9c5be24fb9e6132e97da5a35e55a83e36b9 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54ffccbf053b5b6ca4f6e45094b942fab92a25fc https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... At least the second one says "... leading to use-after-free errors." But style in the Linux community is to not mention security impact and just to give a dense explanation of the bug itself. (Jann Horn, as a person who does care about security, tends to be better about this than most kernel developers; if the fix were from the average subsystem maintainer, I wouldn't expect to even see a mention of "use-after-free.") Also, if you look at the Project Zero bug log (https://bugs.chromium.org/p/project-zero/issues/detail?id=2125 https://bugs.chromium.org/p/project-zero/issues/detail?id=21...), it's clear that Horn wasn't totally sure whether/how this could be exploited, just that it seemed funny. (This should probably lead you to question whether "stable" kernels are a meaningful concept and whether the hypothesis that stable kernels are patched / otherwise do what they claim to do is even falsifiable.)
  - tialaramex 5y ago
    The kindest way to look at the Linux commit behaviour is that almost by definition its bugs are security bugs. The bug means the kernel doesn't behave as intended, and you are entitled from a security point of view to assume it does behave as intended, so, hence bugs are security bugs. And thus argubaly having a "security bug" flag is redundant. For example suppose for some crazy reason, on Sundays all USB audio devices have stereo flipped by mistake. That's a bug. Is it a security bug? At first glance you may think "No". It's just a weird logic bug. But the user is entitled to reason that if they routed stereo left from their USB digital audio feed to the mono "Security Announcements" PA in the building, and their "security announcements" code is silent on stereo right, that's fine, that will still cause the announcements to come from their PA system as desired. It's astonishing that on Sunday this Linux bug silences the PA and they don't get PA announcements that there's a seismic alarm down in gold vaults D, E and F because somebody has drilled into them. It was a security bug after all.
    - shawnz 5y ago
      That seems like a stretch to me. If the hypothetical issue you are describing were caused by a bug in the system's media player software, would you say it's a security bug there too, just because it could be used to play security announcements? With this way of looking at things you are essentially saying that any bug in any software that could be called by other software is a security bug.
      - tialaramex 5y ago
        Yes, I would actually be comfortable with the latter claim in extremis. But here we're talking about the Linux kernel and so we needn't stretch that far. "The buck stops here" so to speak, if you can't trust the OS kernel to do what it promised, you're pretty much screwed. All you have left are broader physical or mathematical guarantees e.g. even a Linux kernel bug at Let's Encrypt can't leak your TLS server private keys because they don't have your private keys and so mathematically that can't happen - or even if there's a really drastic Linux kernel zero day this Android phone can't travel faster than the speed of light because physics doesn't rely on kernel code.
diegocg 5y ago
It is also a local exploit, not a remote one
- Steltek 5y ago
  At some point in my career, I picked up the notion that there an infinite number of local exploits laying around on your average Linux box. Any local user could find their way to root unless you took extra steps to lock things down. I'm not saying that there are still bash one-liners that give you a root prompt. Just that the "attack surface" of privileged binaries and kernel APIs is so enormous that there must be something to leverage. I don't mean to pick on anything unfairly but I figured a specially crafted filesystem or FUSE command would do the trick quite easily. Is that still the case or am I just old?
  - deleted 5y ago
    [deleted]
  - kuroguro 5y ago
    Not sure about the particular setup you mentioned, but given that there's an LPE published every few months, I wouldn't be surprised. https://ssd-disclosure.com/ssd-advisory-overlayfs-pe/ https://ssd-disclosure.com/ssd-advisory-overlayfs-pe/ https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/sequoia-a-local-privilege-escalation-vulnerability-in-linuxs-filesystem-layer-cve-2021-33909 https://blog.qualys.com/vulnerabilities-threat-research/2021...
- amelius 5y ago
  Can it be turned into a remote exploit through a web-browser? (Assuming the user knows what they are doing)
  - geofft 5y ago
    Not without a sandbox escape, at which point you often have more juicy targets without even getting to root (e.g., bank account credentials). The attack requires the ability to open a terminal device and do strange ioctls on it. Web browsers don't open terminal devices at all, so you are pretty unlikely to induce the browser to reuse parts of its code to do it; you'd need the ability to run arbitrary code.

Datagenerator 5y ago

Thank you, security officer on duty goes back to sleep.

perihelions 5y ago

Did Debian-stable not release the patch until February 2021, or did am I confused? https://lists.debian.org/debian-security-announce/2021/msg00024.html https://lists.debian.org/debian-security-announce/2021/msg00... https://tracker.debian.org/news/1226431/accepted-linux-419171-2-source-into-stable-embargoed-stable/ https://tracker.debian.org/news/1226431/accepted-linux-41917...

geofft 5y ago
The commit messages are pretty unclear about whether there's any security impact: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8bcd9c5be24fb9e6132e97da5a35e55a83e36b9 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54ffccbf053b5b6ca4f6e45094b942fab92a25fc https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... At least the second one says "... leading to use-after-free errors." But style in the Linux community is to not mention security impact and just to give a dense explanation of the bug itself. (Jann Horn, as a person who does care about security, tends to be better about this than most kernel developers; if the fix were from the average subsystem maintainer, I wouldn't expect to even see a mention of "use-after-free.") Also, if you look at the Project Zero bug log (https://bugs.chromium.org/p/project-zero/issues/detail?id=2125 https://bugs.chromium.org/p/project-zero/issues/detail?id=21...), it's clear that Horn wasn't totally sure whether/how this could be exploited, just that it seemed funny. (This should probably lead you to question whether "stable" kernels are a meaningful concept and whether the hypothesis that stable kernels are patched / otherwise do what they claim to do is even falsifiable.)
- tialaramex 5y ago
  The kindest way to look at the Linux commit behaviour is that almost by definition its bugs are security bugs. The bug means the kernel doesn't behave as intended, and you are entitled from a security point of view to assume it does behave as intended, so, hence bugs are security bugs. And thus argubaly having a "security bug" flag is redundant. For example suppose for some crazy reason, on Sundays all USB audio devices have stereo flipped by mistake. That's a bug. Is it a security bug? At first glance you may think "No". It's just a weird logic bug. But the user is entitled to reason that if they routed stereo left from their USB digital audio feed to the mono "Security Announcements" PA in the building, and their "security announcements" code is silent on stereo right, that's fine, that will still cause the announcements to come from their PA system as desired. It's astonishing that on Sunday this Linux bug silences the PA and they don't get PA announcements that there's a seismic alarm down in gold vaults D, E and F because somebody has drilled into them. It was a security bug after all.
  - shawnz 5y ago
    That seems like a stretch to me. If the hypothetical issue you are describing were caused by a bug in the system's media player software, would you say it's a security bug there too, just because it could be used to play security announcements? With this way of looking at things you are essentially saying that any bug in any software that could be called by other software is a security bug.
    - tialaramex 5y ago
      Yes, I would actually be comfortable with the latter claim in extremis. But here we're talking about the Linux kernel and so we needn't stretch that far. "The buck stops here" so to speak, if you can't trust the OS kernel to do what it promised, you're pretty much screwed. All you have left are broader physical or mathematical guarantees e.g. even a Linux kernel bug at Let's Encrypt can't leak your TLS server private keys because they don't have your private keys and so mathematically that can't happen - or even if there's a really drastic Linux kernel zero day this Android phone can't travel faster than the speed of light because physics doesn't rely on kernel code.

diegocg 5y ago

It is also a local exploit, not a remote one

Steltek 5y ago
At some point in my career, I picked up the notion that there an infinite number of local exploits laying around on your average Linux box. Any local user could find their way to root unless you took extra steps to lock things down. I'm not saying that there are still bash one-liners that give you a root prompt. Just that the "attack surface" of privileged binaries and kernel APIs is so enormous that there must be something to leverage. I don't mean to pick on anything unfairly but I figured a specially crafted filesystem or FUSE command would do the trick quite easily. Is that still the case or am I just old?
- deleted 5y ago
  [deleted]
- kuroguro 5y ago
  Not sure about the particular setup you mentioned, but given that there's an LPE published every few months, I wouldn't be surprised. https://ssd-disclosure.com/ssd-advisory-overlayfs-pe/ https://ssd-disclosure.com/ssd-advisory-overlayfs-pe/ https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/sequoia-a-local-privilege-escalation-vulnerability-in-linuxs-filesystem-layer-cve-2021-33909 https://blog.qualys.com/vulnerabilities-threat-research/2021...
amelius 5y ago
Can it be turned into a remote exploit through a web-browser? (Assuming the user knows what they are doing)
- geofft 5y ago
  Not without a sandbox escape, at which point you often have more juicy targets without even getting to root (e.g., bank account credentials). The attack requires the ability to open a terminal device and do strange ioctls on it. Web browsers don't open terminal devices at all, so you are pretty unlikely to induce the browser to reuse parts of its code to do it; you'd need the ability to run arbitrary code.