On Tue, Jul 17, 2018 at 05:24:11PM -0700, Rick Moen wrote: > Quoting Adam Borowski ([email protected]): > > > Then there are local exploits. Ted Ts'o for example keeps fuzzying ext4 for > > years yet exploitable bugs still pop up frequently -- usually just DoS but > > arbitrary code execution isn't unheard of. > > I've read a lot of e2fsprogs CVEs, and cannot recall any ever having > been _proved exploitable_ to allow arbitrary code execution. In a > number of cases, there have been bugs, generally buffer overflows, that > in theory could _possibly_ lead to arbitrary code execution that in > theory might exploit privileged code such as e2fsprogs mount code, thus > in theory possibly supporting privilege escalation.
I'm talking about kernel not progs, and those don't get issued CVEs. There's only so much preaching about "don't blindly mount untrusted filesystems" that gets ignored by distros one can do before giving up on the issue. > Where I'm pretty sure you are massively exaggerating is by eliding the > necessary qualifiers 'in theory' and 'possibly' and claiming observed > paths to arbitrary code execution (leveraging privileged routines). > There is a gaping hole between 'buffer overflow that someone might > eventually figure out how to do bad things with' and 'arbitrary code > execution'. A bug is a bug. Most serious kernel developers don't put much heed into whether the problem is exploitable or not, they just fix it. It's only security folks that analyze those. > If we're going to have realistic discussions of security on Dng, it > would help to forego 'Bad things are possible, ergo doomsday just > happened' rhetoric. It's about attack types. Breaking the kernel with nothing but network access is major news (as opposed to taking over a network daemon first). Taking over the daemon is userspace issue thus out of scope for kernel devs, although obviously it's interesting for _users_. As for local exploits, I find it very likely that three-letter-agencies of all major countries do have some kind of ring 0 exploit, the attack surface is big enough. As for physical access exploits, it's pretty much a lost cause. Distros automount filesystems from removable media (USB, SD cards, ...), and this attack avenue alone is enough. I read filesystem-related mailing lists enough to know there's no way there's not a single arbitrary code execution bug _somewhere_, in addition to many many many mere crashers. Thus, that locked laptop is easy pickings. > Concur that USB is a security Typhoid Mary. I would dearly love to see > hardware devices enforcing USB class identities on connected devices, so > that, say, a USB key drive can claim all it wants to be a USB HID-class > device rather than UMS-class, but isn't believed. Short of that, I'm > just really careful what hardware I permit. There's no way to enforce identity: the other side of a connector has no way of verifying that. On the other hand, letting userspace block any new devices of a certain class would fix this particular attack: even for distros that insist on automounting stuff without asking, it's pointless to do so while locked. The only types that make sense are: 1. pure chargers, 2. HID (so you can unlock even if your keyboard got dislodged). Any extra capabilities of the link partner can be queried only after unlocking. That's for laptop/phone-type machines, a server might have a different policy. > Attacks relying on USB devices masquerading as a different class come up > fairly often on Schneier's blog, e.g., > https://www.schneier.com/blog/archives/2011/06/yet_another_peo.html None of the devices in the article fake their class. Blocking automount wouldn't also help here: no matter if you have automount, click-to-mount or root only mount, cases when an user connects an USB stick but doesn't immediately follow with mounting it are extremely, extremely rare. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
