[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1496494600.21640.9.camel@gmail.com>
Date: Sat, 03 Jun 2017 08:56:40 -0400
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel: stack buffer overflow with
controlled payload in get_options() function
> Here's why the Android-based justification given earlier is bogus: you
> can boot from a usb flash drive as real root, without SELinux
> containing
> the init launched from there. It has full control over the kernel. In
> fact, there is no way to contain real root on those devices. They have
> DMA access over the kernel via peripherals that are not contained by
> the
> IOMMU with APIs exposed to userspace offering that control.
I fail to see why this rootfs / initrd / init control matters though. I
can't see how it's a vulnerability. Android covers the kernel line with
verified boot and control over it is a verified boot bypass. If you
found a way to persist as root after getting that temporary root access
via the verified boot bypass, that would be *another* verified boot
bypass, but you can persist as the system user (less than root but not
in a way that matters to a user) by design since vanilla Android doesn't
yet cover enough of userspace with verified boot to do much more than
guarantee that factory resets (which wipe all persistent state, but
don't touch the OS) purge root / system malware.
The DMA access issues matter because some of those processes could be
contained if it wasn't for the driver issues. However, it can't just be
considered a vulnerability unless it was intended for that to be case.
If they intended to contain those processes, it's a vulnerability.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
