I am proud to share that I was elected the Vice Chair of the RISC-V J-extension (so-called J-ext) Task Group 🙂 My last 3-4 years of work on the RISC-V architecture were quite fruitful:
- I am an author of RISC-V Pointer Masking extension:
https://github.com/riscv/riscv-j-extension/blob/master/zjpm-spec.pdf - I am one of the Contributors to RISC-V Control Flow Integrity (CFI):
https://github.com/riscv/riscv-cfi/blob/main/riscv-cfi.pdf - I help driving I/D consistency extension
- HWASAN and Memory Tagging (MTE) on RISC-V
- I found a critical bug in the RISC-V architecture (not in the implementation of a specific processor) that got CVE-2021-1104. Among other things, I talked about this vulnerability in 2021 at the DefCon 29 conference
Thanks,
Adam
This year I’m going to present some amazing research on:
- BlackHat 2021 – “Safeguarding UEFI Ecosystem: Firmware Supply Chain is Hard(coded)” – together with Alex Tereshkin and Alex Matrosov
Abstract: click here - DefCon 29 – “Glitching RISC-V chips: MTVEC corruption for hardening ISA” – together with Alex Matrosov
Abstract: click here
Both of them are really unusual and interesting topics 😉
If anyone is going to be in Las Vegas during BlackHat and/or DefCon this year and would like to grab a beer, just let me know!
Thanks,
Adam
24
Jan
Blind TCP/IP hijacking is still alive on Windows 7… and not only. This version of Windows is certainly one of the “juiciest” targets even though January 14th 2020 was the official EOL (End Of Life) for it. Based on various data Windows 7 holds around 25% share of the Operating Systems (OS) market and is still the world’s second most popular desktop operating system.
Read moreThe short story of broken KRETPROBES and OPTIMIZER in Linux Kernel.
During the LKRG development process I’ve found that:
- KRETPROBES are broken since kernel 5.8 (fixed in upcoming kernel)
- OPTIMIZER was not doing sufficient job since kernel 5.5
I would like to draw draw attention to the following Openwall’s tweet:
and the full post on LKRG’s mailing list here:
https://www.openwall.com/lists/lkrg-users/2020/06/14/5
Thanks,
Adam
I’ve recently spent some time looking at ‘exec_id’ counter. Historically, Linux kernel had 2 independent security problems related to that code: CVE-2009-1337 and CVE-2012-0056.
Until 2012, ‘self_exec_id’ field (among others) was used to enforce permissions checking restrictions for /proc/pid/{mem/maps/…} interface. However, it was done poorly and a serious security problem was reported, known as “Mempodipper” (CVE-2012-0056). Since that patch, ‘self_exec_id’ is not tracked anymore, but kernel is looking at process’ VM during the time of the open().
In 2009 Oleg Nesterov discovered that Linux kernel has an incorrect logic to reset ->exit_signal. As a result, the malicious user can bypass it if it execs the setuid application before exiting (->exit_signal won’t be reset to SIGCHLD). CVE-2009-1337 was assigned to track this issue.
The logic responsible for handling ->exit_signal has been changed a few times and the current logic is locked down since Linux kernel 3.3.5. However, it is not fully robust and it’s still possible for the malicious user to bypass it. Basically, it’s possible to send arbitrary signals to a privileged (suidroot) parent process.
I’ve summarized my analysis and posted on LKML:
https://lists.openwall.net/linux-kernel/2020/03/24/1803
and kernel-hardening mailing list:
https://www.openwall.com/lists/kernel-hardening/2020/03/25/1
Btw. Kernels 2.0.39 and 2.0.40 look secure 😉
Thanks,
Adam
21
Mar
On 28th of February, I’ve sent a short summary to lkrg-users mailing list (https://www.openwall.com/lists/lkrg-users/2020/02/28/1) regarding recent Linux kernel XFRM UAF exploit dropped by Vitaly Nikolenko. I believe it is worth reading and I’ve decided to reference it on my blog as well:
Read moreFelix Wilhelm recently tweeted a Proof of Concept (PoC) of container escape abusing release agent for cgroup v1.
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
mkdir -p $d/w;echo 1 >$d/w/notify_on_release
t=`sed -n 's/.*perdir=([^,]*).*/1/p' /etc/mtab`
touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh
$1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o— Felix Wilhelm (@_fel1x) July 17, 2019
To be able to perform the attack, container was run with the “–privileged” flag which is not a setup for security anyway. When using this flag, containers have full access to all devices and lack restrictions from seccomp, AppArmor, and Linux capabilities. Nevertheless, “–privileged” flag is just a simplification of the necessary requirements for this attack, which is SYS_ADMIN capability for the container itself, as well as VFS for cgroup v1 mount with the read and write permission.
Felix was able to inject a custom command into the mechanism known as a “notify_on_release” in cgroup v1. When the last task in a cgroup leaves it, a release agent is executed by the kernel via call_usermodehelper_exec() (UserModeHelper – UMH) mechanism. Since the kernel is doing ‘clean-up’, UMH is executed on the host outside of the namespace / container.
More information about release_agent can be found here:
https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
Linux Kernel Runtime Guard (LKRG) has functionality of limiting an UMH interface. By default, it is allowed to execute only LKRG’s whitelisted programs. For some people it might be not enough and in that case LKRG has an ability to fully lock UMH and nothing can be executed via this interface. This might break things if your distro uses UMH to invoke any programs e.g. if you are using release_agent 😉
You can see how LKRG can save you by preventing and detecting Felix’s container escape (based on UMH) here:
Thanks,
Adam
3
Apr
One of the author of Windows Internals (Andrea Allievi) asked me and my friend David Kaplan if we could write a section about System Guard Runtime Attestation for their book. We’ve written about 3-4 pages describing internals of that project which we fully designed. Our section will be included in Windows Internals 7th edition part 2 (release date around August 2019):
Windows Defender System Guard Runtime Attestation (SGRA / SGRM) is internally known as a project Octagon which me and Dave fully designed and implemented together with Octagon v-team. Octagon is now included in every Windows build and first implementation of this new technology has been introduced in Windows 10 April 2018 Update (RS4). You can learn more about this project here:
Best regards,
Adam
19
Feb
Hi,
We’ve just announced a new version of LKRG 0.6! This release is… BIG! A few words why:
- We've introduced a new mitigation features which we call "poor's man CFI" (pCFI). It is designed to "catch" exploits which corrupts stack pointer to execute ROP and/or execute code not from the official .text section of the kernel (e.g. from the heap page, or user-mode page)
- We are using pCFI to enforce SMEP bit in CR4 and WP bit in CR0. If attacker disables one of that bits, LKRG will re-enable it again
- We've locked-down usermodehelper (UMH) interface - it will kill "class" of exploit abusing UMH
- We've completely rewrote *_JUMP_LABEL support - now it is independent of CPU architecture and can work on any CPU. Previously it was designed for x86 arch. New *_JUMP_LABEL support logic significantly reduce memory footprint, remove whitelisting, simplifies some algorithms and so on...
- We've introduce early boot systemd script/unit. Now you can easily manage LKRG service as any other service in the system. Systemd is the only init system which we support for now, but there is no reason to add support for other systems.
- We've fixed a few known problems with LKRG and made it more stable
- We've made all necessary changes to run LKRG on latest kernels
- A few more!
It’s a big release with a lot of changes. Full announcement can be found here:
https://www.openwall.com/lists/announce/2019/02/19/1
Next, I would like to work on ARM support for LKRG. Stay tuned….