Quoting Adam Borowski (kilob...@angband.pl):
> I'm talking about kernel not progs, and those don't get issued CVEs.
1. Kernels get CVEs.
2. The lion's share of ext4 security-sensitive bugs have been in
e2fsprogs code.
3. I'm disappointed to have (by implication) politely invited you to support
your claim about 'arbitrary code execution', and not yet heard any.
I'd still be interested, if you can cite any examples.
> 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.
Begging your pardon, Adam, but I think somehow we're miscommunicating,
as this seems unresponsive to what I said. I really wasn't trying to
pick an argument, however.
> > 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.
{sigh}
You seem, here, to talk around my critique without addressing it. Oh
well.
> > 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_.
Again, you seem to have ignored my point.
> 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.
Speak for yourself, sir. ;-> My Linux systems don't run automounters,
for starters. (I'm sorry to hear about unwise distro installation
defaults, but they aren't _my_ problem.)
> > 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.
I think you must have either misunderstood what I said, and/or just
simply aren't addressing it.
A candidate hardware solution might a 'filter adapter' pluggable into a
host USB port and have a switch to select one at a time of the 20
assigned USB classes (of which the most everyday-familiar are HID,
printer, and UMS). Then, you plug the peripheral into the filter
adapter. The latter, if configured to allow only UMS devices, waits
until the peripheral declares as part of USB handshaking its Vendor ID
(VID), Product ID (PID), and serial number (iSerial). These data
suffice for the filter adapter to determine what USB class the
peripheral is claiming to be, and either allows or disallows the USB
information to progress through to the host computer -- depending on how
you habe the USB class switch set. I.e., if the supposed UMS device is
lying and claiming to be a HID one, so it can function as a keyboard,
the filter adapter would deny the connection.
A simpler solution would be for a simpler intermediate USB device to
merely pop up on an LCD display the above claimed device information
offered for handshaking (ideally displaying a more-complete description
from table lookup) and prompt the user 'Accept device 'y/N?' before
enumerating it.
Neither of these is a perfect solution, but is a whole lot better than
just plugging in a device and trusting it to Do the Right Thing.
I follow Schneier's blog (and similar outlets such as RISKS Digest) only
occasionally, but I could swear that there have been some innovative
products at least as prototypes mentioned in such places from time to
time.
I'm not a hardware designer, so I am certainly not, in the above
paragraphs, claiming to have a workable plan let alone a tested one.
I'm just suggesting the sorts of things that could be attempted, to
improve over the 'plug it in and trust it' model. And, even if I
haven't seen the _exact_ techniques I outline, I'm reasonably certain
I've seen competent plans to do similar things using hardware solutions.
> > 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.
But are mentioned in the comments, which is what I expected you'd
bother to skim-read. (But suit yourself.)
Web-forum comments _in general_ are, as has been memorably said about
those on YouTube, 'where souls go to die'. However, there are honourable
exceptions, and I'd suggest they include the rather-better-than-useless
comment sections on schneier.com, lwn.net, and RISKS Digest. (But I'll
admit to bias, as a participant on all three.)
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
