* [kernel-hardening] get NULL pointer dereferences or #GP fault to infomation leakage @ 2016-11-19 11:50 zerons 2016-11-19 16:36 ` Thomas Garnier 0 siblings, 1 reply; 5+ messages in thread From: zerons @ 2016-11-19 11:50 UTC (permalink / raw) To: kernel-hardening 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? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] get NULL pointer dereferences or #GP fault to infomation leakage 2016-11-19 11:50 [kernel-hardening] get NULL pointer dereferences or #GP fault to infomation leakage zerons @ 2016-11-19 16:36 ` Thomas Garnier 2016-11-20 2:12 ` zerons 0 siblings, 1 reply; 5+ messages in thread From: Thomas Garnier @ 2016-11-19 16:36 UTC (permalink / raw) To: Kernel Hardening [-- Attachment #1: Type: text/plain, Size: 702 bytes --] 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@gmail.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 [-- Attachment #2: Type: text/html, Size: 1144 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] get NULL pointer dereferences or #GP fault to infomation leakage 2016-11-19 16:36 ` Thomas Garnier @ 2016-11-20 2:12 ` zerons 2016-11-20 16:49 ` Thomas Garnier 0 siblings, 1 reply; 5+ messages in thread From: zerons @ 2016-11-20 2:12 UTC (permalink / raw) To: kernel-hardening 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@gmail.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? >> > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] get NULL pointer dereferences or #GP fault to infomation leakage 2016-11-20 2:12 ` zerons @ 2016-11-20 16:49 ` Thomas Garnier 2016-11-20 23:21 ` zerons 0 siblings, 1 reply; 5+ messages in thread From: Thomas Garnier @ 2016-11-20 16:49 UTC (permalink / raw) To: Kernel Hardening [-- Attachment #1: Type: text/plain, Size: 1938 bytes --] 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@gmail.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@gmail.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 [-- Attachment #2: Type: text/html, Size: 2857 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] get NULL pointer dereferences or #GP fault to infomation leakage 2016-11-20 16:49 ` Thomas Garnier @ 2016-11-20 23:21 ` zerons 0 siblings, 0 replies; 5+ messages in thread From: zerons @ 2016-11-20 23:21 UTC (permalink / raw) To: kernel-hardening Yes, thanks for your reply, I didn't think that through.:) On 11/21/2016 12:49 AM, Thomas Garnier wrote: > 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@gmail.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@gmail.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? >>>> >>> >>> >>> >> > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-11-20 23:21 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-19 11:50 [kernel-hardening] get NULL pointer dereferences or #GP fault to infomation leakage zerons 2016-11-19 16:36 ` Thomas Garnier 2016-11-20 2:12 ` zerons 2016-11-20 16:49 ` Thomas Garnier 2016-11-20 23:21 ` zerons
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.