From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 In-Reply-To: References: From: Thomas Garnier Date: Sat, 19 Nov 2016 08:36:33 -0800 Message-ID: Content-Type: multipart/alternative; boundary=001a114848308fd7280541aa0627 Subject: Re: [kernel-hardening] get NULL pointer dereferences or #GP fault to infomation leakage To: Kernel Hardening List-ID: --001a114848308fd7280541aa0627 Content-Type: text/plain; charset=UTF-8 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 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 --001a114848308fd7280541aa0627 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It is an issue because having KASLR enable without panic o= n oops is not really useful. Same apply to other mitigations that rely on r= andomness.

O= n Sat, Nov 19, 2016 at 3:50 AM, zerons <zeronsaxm@gmail.com> wrote:

I wonder if this could be an is= sue.

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

--001a114848308fd7280541aa0627--