Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Linux udisks flaw lets attackers get root on major Linux distros

bleepingcomputer.com

Post reply on HN
Print view View original

211–220 of 287 posts

Re: New Linux udisks flaw lets attackers get root on major Linux distros

#211

Post by burnt-resistor »

SEJeff wrote: post #200
tptacek wrote: post #189

Earlier quoted context omitted.

They don't work as reliable security boundaries; they're developer/ops tools.

Thomas, what are your thoughts on micro-vms such as kata containers? You can use them as a backend for docker in place of runc. I'm sure you're well aware, but for the readers, they are isolated with a CPU's VT instructions which are built to isolate VMS. I still think "containers don't contain" in a very Dan Walsh boston accent, but this seems like a respectable start. https://katacontainers.io

They're slow and so unsuitable for dev work. They might be somewhat better for prod, but it depends on a wide selection of unproven hypervisors.

Re: New Linux udisks flaw lets attackers get root on major Linux distros

#212

Post by mrspuratic »

pona-a wrote: post #75
selfmodruntime wrote: post #71

Earlier quoted context omitted.

I can't for the life of me find a list of 210 sudo CVE's. Are you sure this is correct?

I got it from here [0]. I didn't notice it was a keyword search, so it's an overcount. Thanks for correcting me. Going off its security advisories page [1] and this tracker [2], it seems to be around 43 CVEs, most rated high severity. So the actual rate would be 43 CVE / 430 kLoC = ~0.01 CVE per kLoC, so ~2.65 CVEs for udisks and ~0.2 for pmount. [0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sudo [1] https://w…

You can search by CPE here: https://nvd.nist.gov/products/cpe/search and search for e.g.:

    cpe:2.3:a:sudo_project:sudo:*:*:*:*:*:*:*:*
    cpe:2.3:a:todd_miller:sudo:*:*:*:*:*:*:*:*
The above pair are the same "sudo", but split arbitrarily, perhaps varying by assigning authority preference. (There are some other "sudo" named projects too).

Those CPE IDs were determined by a brute-force-ish XML grep:

    xml select -N cpe-23="http://scap.nist.gov/schema/cpe-extension/2.3" -t --match '//cpe-23:cpe23-item' --if 'contains(@name,":sudo:")'  -v "@name" -n official-cpe-dictionary_v2.3.xml
Now, mapping CVECPE is a tricker problem, it's not 1:1 (a single CVE can affect multiple product versions), and harder here since sudo (1986-ish) predates CVEs (1999) by a decade, and CPE (2009) by two. The most capable searches seem to be via non-free APIs or "vulnerability management $olutions", plus a few CLIs tools that need a lot of care and feeding.

This web service is free: https://cve.circl.lu/ But, you cannot search directly by CPE right now; you can start a search by vendor, then filter by product:

    todd_miller sudo: 58 vulnerabilities
    sudo_project sudo: 42 vulnerabilities
Except, for reasons I don't understand, there are duplicates because they somehow source "unique" but overlapping CVEs from multiple databases. The true number might be 50 combined, of varying severity/concern, but I give up now. I'm going to go mutter into my beard for a while.

Re: New Linux udisks flaw lets attackers get root on major Linux distros

#213

Post by DCKing »

PhilipRoman wrote: post #57

Local privesc, don't care. If anyone still thinks that they can draw a security boundary anywhere with a shared kernel, they should really look at kernel CVE database (and be horrified). For every fancy titled exploit there are twenty that you've never heard of. You can sort of do it if you carefully structure your program to restrict syscall use and then use some minimal and well audited syscall filtering layer to h…

> they should really look at kernel CVE database

When quoting kernel CVEs as evidence as signs of insecurity, especially so seemingly authoritatively, please make sure you're informed about how what Linux kernel CVEs mean.

A CVE (for any product) does not automatically mean there is actually a vulnerability there or even if one is exploitable unless explicitly noted (in the CVE or credibly by someone else). Proof of concepts, reproducibility or even any kind of verification are not a part of the CVE process.

For the Linux kernel in particular, the CVE process is explicitly to be "overly cautious" [1]. In practice, this means the Linux security team requests a CVE for anything that has a mere whiff of being theoretically exploitable. Of course that doesn't mean that the bug that was fixed was actually exploitable, not even theoretically but certainly not in practice.

As a result, you can't use CVEs reported by the Linux kernel to make claims about the (lack of) practical security of any Linux system, including your desktop. The CVEs reported by the Linux kernel are there to notify you to very well informed users of the kernel to do further risk assessments, not to be taken at face value as a sign of insecurity. [The latter is true for the entire CVE system - they're not to be taken at face value as signs something is wrong. But it's especially true for the kernel.]

[1]: https://docs.kernel.org/process/cve.html#process

Re: New Linux udisks flaw lets attackers get root on major Linux distros

#215

Post by andrewmcwatters »

DCKing wrote: post #213
PhilipRoman wrote: post #57

Local privesc, don't care. If anyone still thinks that they can draw a security boundary anywhere with a shared kernel, they should really look at kernel CVE database (and be horrified). For every fancy titled exploit there are twenty that you've never heard of. You can sort of do it if you carefully structure your program to restrict syscall use and then use some minimal and well audited syscall filtering layer to h…

> they should really look at kernel CVE database When quoting kernel CVEs as evidence as signs of insecurity, especially so seemingly authoritatively, please make sure you're informed about how what Linux kernel CVEs mean. A CVE (for any product) does not automatically mean there is actually a vulnerability there or even if one is exploitable unless explicitly noted (in the CVE or credibly by someone else). Proof of…

This is a common complaint with the whole CVE process to begin with, and isn't even a Linux thing.

Re: New Linux udisks flaw lets attackers get root on major Linux distros

#216

Post by tptacek »

burnt-resistor wrote: post #211
SEJeff wrote: post #200

Earlier quoted context omitted.

Thomas, what are your thoughts on micro-vms such as kata containers? You can use them as a backend for docker in place of runc. I'm sure you're well aware, but for the readers, they are isolated with a CPU's VT instructions which are built to isolate VMS. I still think "containers don't contain" in a very Dan Walsh boston accent, but this seems like a respectable start. https://katacontainers.io

They're slow and so unsuitable for dev work. They might be somewhat better for prod, but it depends on a wide selection of unproven hypervisors.

Which "unproven" hypervisors are those? Kata works with Firecracker.

Re: New Linux udisks flaw lets attackers get root on major Linux distros

#217

Post by spookie »

scheeseman486 wrote: post #96
stephenr wrote: post #91

Earlier quoted context omitted.

> It's permissively licensed, unfortunately. Well damn that's a shame. I just hate it when people let others use their work in a way they choose, that happens to be less restrictive than my own personal choices. /s of course.

Worked out for Linux, which remains a largely open, collaborative ecosystem. Meanwhile all the BSDs are good for are as less-good Linuxes that can be shoved into proprietary products. Google is choking out AOSP, which they can do because of Android's "less restrictive" license. Copyleft licenses are demonstrably better for open source projects in the long run. We've had enough time to prove that out now.

Good take. Also note the very well thought out decision from Linus and team to keep GPLv2, it is a balancing game.

In the end, if you want projects to succeed they need contributors. Unfortunately, some of them need to be reminded to play fair more than others, and in those cases the legalese helps.

Re: New Linux udisks flaw lets attackers get root on major Linux distros

#218

Post by akdev1l »

simoncion wrote: post #20
TheDong wrote: post #15

Earlier quoted context omitted.

The article was about two issues that combine to make a single local-privilege-escalation, so the PAM thing isn't a separate exploit chain, it's just part of getting local root in this vulnerability. What the parent poster meant is that you first need a way to run arbitrary code before local privilege escalation matters, so the exploit chain has to include _something_ that gets you local code execution. I tend to agr…

> ...for most modern single-user linux devices, local privilege escalation means almost nothing. I haven't actually looked at the numbers, but I strongly suspect that it's true that the overwhelming majority of single-user Linux devices out there are Android devices. If that's true, then it's my understanding that Android does bother to fairly properly sandbox programs from each other... so an escalation to root woul…

Android is not a single user system. Every app, every service basically everything gets its own user.

Applications have different user IDs and different SELinux contexts.

Android security is tight

Re: New Linux udisks flaw lets attackers get root on major Linux distros

#219

Post by stefan_ »

holowoodman wrote: post #178
stefan_ wrote: post #168

Earlier quoted context omitted.

Ironically Ubuntu 24 now blocks users from accessing namespaces because that kernel interface had a bunch of local privilege escalations, breaking programs that want to use them for isolation.

For the last 10 years or so, namespaces in Linux were the source of the absolute hightest number of local privilege escalations and sometimes even arbitrary code executions in kernel space. Building a kernel without user namespace support has been goto-advice for multiuser systems for almost as long. Ubuntu is just late to the game because they mostly have server or single-user-desktop customers.

Actually I think device drivers got you beat there, but no ones suggesting we break them for users safety. Ubuntu today is more user hostile than Windows.

Re: New Linux udisks flaw lets attackers get root on major Linux distros

#220

Post by stefan_ »

immibis wrote: post #187
ranger_danger wrote: post #183

Earlier quoted context omitted.

Seems ironic considering namespaces are highly utilized for isolation/security purposes.

I presume they're left enabled for root.

The same software that wants to use namespaces for isolation will refuse to run as root.
Post reply on HN