On Wed, 18 Jul 2018 at 03:21:14 +0200 Adam Borowski <kilob...@angband.pl> wrote:
> On Tue, Jul 17, 2018 at 05:24:11PM -0700, Rick Moen wrote: >> Quoting Adam Borowski (kilob...@angband.pl): >> >>> 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. A 5 secs search for "linux kernel CVE" disagrees with you: https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 Why on Earth would ever a kernel vulnerability not be issued a CVE? > 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. What do user's securitity malpractises have to do with kernel backdoors? >> 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. And it's not a backdoors. > 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. Right. Hoever, how does this address Rick's observations? >> 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_. Yawnn... > 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. More off-topic babbling. > 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. As before. >> 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. OK. How could thst become a backdoor, please? A *kernel* backdoor? > 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. Does the subject line read "A Devuan kernel?" or does it read "An all-round security audit of Devuan?" >> 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. I suppose you don't run Linux out of security concerns, do you? Alessandro _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
