linux-kernel - [PATCH 0/2] kprobe: Fix: add symbols to kprobe blacklist

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1500044315-9508-1-git-send-email-francis.deslauriers@efficios.com>
Date:   Fri, 14 Jul 2017 10:58:33 -0400
From:   Francis Deslauriers <francis.deslauriers@...icios.com>
To:     rostedt@...dmis.org, mhiramat@...nel.org, peterz@...radead.org
Cc:     mathieu.desnoyers@...icios.com, linux-kernel@...r.kernel.org,
        Francis Deslauriers <francis.deslauriers@...icios.com>
Subject: [PATCH 0/2] kprobe: Fix: add symbols to kprobe blacklist

Hi all,

While fuzzing the Perf kprobe and kretprobe interfaces, I found some inputs
that trigger crashes of a 4.12 kernel(6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c)
on a x86-64 VM. I know that K(ret)probes can crash the kernel in multiple ways
but should Perf be allowed to do it?

To do this analysis, I used the symbols reported by /proc/kallsyms in
conjonction with the Perf debugfs interface. Using this technique, I was able
to find two instrumentation configurations that could crash the kernel. I am
suggesting changes that fixed both issues for me by blacklisting the symbols in
question.

Kprobe on apic_timer_interrupt:
I believe that this is caused by the fact that kprobe adds a INT3 in a apic
interrupt routine.
How to reproduce:
	echo 'p:event1 apic_timer_interrupt ' > kprobe_events
	<Generate kernel activity. e.g. launch bash>
Crash log:[1]

This can be fixed by blacklisting the apicinterrupt3 symbols directly in the
assembly macro. See patch[1/2]. I am not sure that blacklisting all
apicinterrupt symbols is the right solution.

Kretprobe on ftrace_ops_assist_func and another function:
Those crashes are triggered when hooking a kretprobe on the
ftrace_ops_assist_func symbol and some other functions to make the this first
function reacheable. From my understanding, ftrace_ops_assist_func is the
function called directly when the kprobe is hit. Thus it should be marked
with NOKPROBE_SYMBOL.

Here are some configurations that can easily reproduce this bug. Those other
functions are called during the fork of a process so they are easy to control.
Enable the following kprobes and launch a process to trigger a fork to see the
kernel crash.

Conf #1
	echo 'r:event1 ftrace_ops_assist_func' > kprobe_events
	echo 'r:event2 clear_all_latency_tracing' > kprobe_events
Crash log:[2]

Conf #2
	echo 'r:event1 ftrace_ops_assist_func' > kprobe_events
	echo 'r:event2 acct_clear_integrals' > kprobe_events
Crash log:[3]

Conf #3
	echo 'r:event1 ftrace_ops_assist_func' > kprobe_events
	echo 'r:event2 arch_dup_task_struct' > kprobe_events
Crash log:[4]

The ftrace_ops_assist_func should be included in the kprobe blacklist using
NOKPROBE_SYMBOL. See patch [2/2].

Since those were found using fuzzing, it's not an exhaustive analysis.
Here is the .config I am using[5].

Thanks,

Francis Deslauriers
EfficiOS inc.

[1]: https://pastebin.com/Mpp9Yzqb
[2]: https://pastebin.com/CtsfzUwG
[3]: https://pastebin.com/txxuJXrz
[4]: https://pastebin.com/8qrJvzD3
[5]: https://pastebin.com/x5q0sgyK

Francis Deslauriers (2):
  kprobe: fix: Add _ASM_NOKPROBE to x86 apic interrupt macro
  kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist

 arch/x86/entry/entry_64.S | 1 +
 kernel/trace/ftrace.c     | 2 ++
 2 files changed, 3 insertions(+)

-- 
2.7.4