[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 May 2017 14:16:13 -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
> This might or might not be a valid point, but I think handling the
> issue
> via the distros list (and thus with an embargo) was wrong. It would
> have been better to have this discussion (if we must) on oss-security
> right away, rather than only now when a second related issue is
> brought
> in here later same month.
init= is just an example. Can also do things like enabling kernel kgdb /
other debugging via headphone port / usb. Can mess with a lot of things
via the kernel line. Disable the IOMMU, get full DMA access via USB-C
perhaps. There are so many things that can be messed with and it really
makes no sense to consider them vulnerabilities without doing something
like *whitelisting* kernel cmdline arguments. Another easy one: disable
dm-verity or change the dm-verity key, bypassing verified boot for the
rest of the OS.
Obtaining CVEs for these bugs presumes that the kernel line is not
absolutely trusted by design, which it is. A CVE wouldn't be accepted
for each of a hundred cmdline arguments that puts intentional trust in
the cmdline, so it really shouldn't be accepted for ones that put
unintentional trust in it. They are memory corruption bugs and should
probably be fixed... but it's about as important as fixing the code
style, not a security fix.
The security fix for Android was CVE-2016-10277 in
https://source.android.com/security/bulletin/2017-05-01
I really don't buy into the idea the arbitrarily chosen methods to gain
code exec via the cmdline are vulnerabilities themselves because there
are many that don't even require bugs...
Might as well consider disabling NX, kernel rodata protection, setting
up the IOMMU, setting memory region addresses (including breaking it /
corrupting memory), etc. to be mitigation bypasses / vulnerabilities if
these count.
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.
