[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJcbSZH2H2rd8f8Mg2NBxfTUdSWLyU_KrZbdZ=imKZNTjJjGSQ@mail.gmail.com>
Date: Sun, 20 Nov 2016 08:49:53 -0800
From: Thomas Garnier <thgarnie@...gle.com>
To: Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: get NULL pointer dereferences or #GP fault to
infomation leakage
I agree that restricting access / filtering dmesg or equivalents is a good
thing.
An oops highlights that something went wrong and the OS should not continue
in this state. If you allow oops then an attacker might bruteforce KASLR
offsets for the kernel base, have multiple attempts at an heap overflow or
against a stack cookie. Many mitigations rely on the fact that the attacker
have only one attempt.
Taking your example on NULL pointer deref. It can be a simple pointer not
checked for NULL or a corrupted object. Not panicing leaves more room for
an attacker to reliably exploit a vulnerability.
Btw, Kees wrote this list of recommended settings:
http://kernsec.org/wiki/index.php/Kernel_Self_Protection_
Project#Recommended_settings
On Sat, Nov 19, 2016 at 6:12 PM, zerons <zeronsaxm@...il.com> wrote:
> If kernel panic on oops, then NULL pointer deref and others may cause a
> DoS.
> Maybe restrict user access to dmesg and other log files so that
> unprivileged
> users couldn't read log messages, or something like /proc/kallsyms(output
> 0000
> if no permission). Then those faults stll be useless.
>
> On 11/20/2016 12:36 AM, Thomas Garnier wrote:
> > It is an issue because having KASLR enable without panic on oops is not
> > really useful. Same apply to other mitigations that rely on randomness.
> >
> > On Sat, Nov 19, 2016 at 3:50 AM, zerons <zeronsaxm@...il.com> wrote:
> >
> >> I wonder if this could be an issue.
> >>
> >> Test on Ubuntu 16.04 with linux kernel 4.4.x, x86_64.
> >>
> >> When a NULL-pointer-deref or a #GP fault
> >> (e.g: access to 0xdead0000-xxxxxxxx) happens in kernel space,
> >> it seems that the kernel would kill the current process, then
> >> output the Oops message or "general protection fault" message.
> >>
> >> So we can get these messages via `dmesg` or reading the /var/log/...
> >>
> >> I think this may be a way to bypass the KASLR, could it be?
> >>
> >
> >
> >
>
--
Thomas
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
