<story><title>mimmutable() for OpenBSD</title><url>https://lwn.net/SubscriberLink/915640/53bc300d11179c62/</url></story><parent_chain><item><author>Sirened</author><text>&amp;gt;One of those marks executable memory that is empowered to call into the kernel; on OpenBSD systems, only the C library is given that capability. That will prevent hostile code loaded elsewhere from making direct system calls; protecting the rest of a process with mimmutable() will prevent the changing of protections to allow system calls from elsewhere (such changes would be done with msyscall() on OpenBSD).&lt;p&gt;This is, unfortunately, a continuation of OpenBSD&amp;#x27;s long tradition of security &amp;quot;mitigations&amp;quot; that are entirely detached from any actual understanding of exploitation [1]. The above suggestion that attackers can no longer make syscalls from their shellcode, while ostensibly true, is moot because you can simply JOP to one of the authorized syscall instructions and entirely defeat the mitigation. Even if mimutable &lt;i&gt;outright prevented any new code from being mapped&lt;/i&gt;, this still wouldn&amp;#x27;t really stop anyone; just look at iOS where attackers have thrived despite there only being one process on the entire OS which is able to map arbitrary code.&lt;p&gt;&amp;gt; Whenever a process enters the kernel, its stack pointer is checked to see whether it is, indeed, pointing into a stack region; if not, the process is killed.&lt;p&gt;This too is trivially defeated. You simply need to add another stage to your payload in which you copy your ROP payload onto the legitimate stack, pivot, and continue executing. If you managed to pivot off the original stack, you already have a pivot gadget and so you only then need to trigger a call to memcpy. This mitigation isn&amp;#x27;t stopping any real attacker.&lt;p&gt;While I never hope to discourage kernel developers from thinking about security mitigations, I think it is really important that people working on these mitigations actually converse with people who &lt;i&gt;write exploits&lt;/i&gt;. Other vendors have seen considerable success with their mitigations [2] in that they specifically target things that attackers need and want to do, such as heap spray.&lt;p&gt;[1] See: ROP gadget elimination, a feature which does not actually stop ROP but merely hopes that &amp;quot;a substantial reduction of gadgets is powerful.&amp;quot; &amp;lt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;marc.info&amp;#x2F;?l=openbsd-tech&amp;amp;m=150317547021396&amp;amp;w=2&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;marc.info&amp;#x2F;?l=openbsd-tech&amp;amp;m=150317547021396&amp;amp;w=2&lt;/a&gt;&amp;gt;. Speaking from experience and having written plenty of actual exploits on attacker hostile platforms, trying to block code execution against an attacker who already has kernel read&amp;#x2F;write is an utterly ridiculous idea because even if you manage to stamp out every single ROP gadget, they can just go and stomp on your kernel page tables to map new kernel code. Even baring that, kernel R&amp;#x2F;W is still a complete compromise even if kernel code execution is somehow impossible because you can still just use R&amp;#x2F;W to bypass any control the kernel could ever hope to enforce.&lt;p&gt;[2] Life and death of an iOS attacker by Luca Todesco  &amp;lt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=8mQAYeozl5I&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=8mQAYeozl5I&lt;/a&gt;&amp;gt;, a discussion of exploit mitigations on iOS and the exponential cost of defeating mitigations on iOS. Luca&amp;#x27;s company writes exploits for iOS devices as a service and he is extremely knowledgable in this area.</text></item></parent_chain><comment><author>daneel_w</author><text>&lt;i&gt;&amp;gt; &amp;quot;This too is trivially defeated. You simply need to add another stage to your payload in which you copy your ROP payload onto the legitimate stack, pivot, and continue executing.&amp;quot;&lt;/i&gt;&lt;p&gt;Have you, or someone else as knowledgeable as you, been able to provide a succesful POC doing this? I admit that I haven&amp;#x27;t gone about looking for results on this topic and method of attack but I would be very interested in reading about it and see a practical example achieving it, since it&amp;#x27;s (in your own words) trivially defeated and simply needs just this or that thing.</text></comment>
<story><title>mimmutable() for OpenBSD</title><url>https://lwn.net/SubscriberLink/915640/53bc300d11179c62/</url></story><parent_chain><item><author>Sirened</author><text>&amp;gt;One of those marks executable memory that is empowered to call into the kernel; on OpenBSD systems, only the C library is given that capability. That will prevent hostile code loaded elsewhere from making direct system calls; protecting the rest of a process with mimmutable() will prevent the changing of protections to allow system calls from elsewhere (such changes would be done with msyscall() on OpenBSD).&lt;p&gt;This is, unfortunately, a continuation of OpenBSD&amp;#x27;s long tradition of security &amp;quot;mitigations&amp;quot; that are entirely detached from any actual understanding of exploitation [1]. The above suggestion that attackers can no longer make syscalls from their shellcode, while ostensibly true, is moot because you can simply JOP to one of the authorized syscall instructions and entirely defeat the mitigation. Even if mimutable &lt;i&gt;outright prevented any new code from being mapped&lt;/i&gt;, this still wouldn&amp;#x27;t really stop anyone; just look at iOS where attackers have thrived despite there only being one process on the entire OS which is able to map arbitrary code.&lt;p&gt;&amp;gt; Whenever a process enters the kernel, its stack pointer is checked to see whether it is, indeed, pointing into a stack region; if not, the process is killed.&lt;p&gt;This too is trivially defeated. You simply need to add another stage to your payload in which you copy your ROP payload onto the legitimate stack, pivot, and continue executing. If you managed to pivot off the original stack, you already have a pivot gadget and so you only then need to trigger a call to memcpy. This mitigation isn&amp;#x27;t stopping any real attacker.&lt;p&gt;While I never hope to discourage kernel developers from thinking about security mitigations, I think it is really important that people working on these mitigations actually converse with people who &lt;i&gt;write exploits&lt;/i&gt;. Other vendors have seen considerable success with their mitigations [2] in that they specifically target things that attackers need and want to do, such as heap spray.&lt;p&gt;[1] See: ROP gadget elimination, a feature which does not actually stop ROP but merely hopes that &amp;quot;a substantial reduction of gadgets is powerful.&amp;quot; &amp;lt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;marc.info&amp;#x2F;?l=openbsd-tech&amp;amp;m=150317547021396&amp;amp;w=2&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;marc.info&amp;#x2F;?l=openbsd-tech&amp;amp;m=150317547021396&amp;amp;w=2&lt;/a&gt;&amp;gt;. Speaking from experience and having written plenty of actual exploits on attacker hostile platforms, trying to block code execution against an attacker who already has kernel read&amp;#x2F;write is an utterly ridiculous idea because even if you manage to stamp out every single ROP gadget, they can just go and stomp on your kernel page tables to map new kernel code. Even baring that, kernel R&amp;#x2F;W is still a complete compromise even if kernel code execution is somehow impossible because you can still just use R&amp;#x2F;W to bypass any control the kernel could ever hope to enforce.&lt;p&gt;[2] Life and death of an iOS attacker by Luca Todesco  &amp;lt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=8mQAYeozl5I&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=8mQAYeozl5I&lt;/a&gt;&amp;gt;, a discussion of exploit mitigations on iOS and the exponential cost of defeating mitigations on iOS. Luca&amp;#x27;s company writes exploits for iOS devices as a service and he is extremely knowledgable in this area.</text></item></parent_chain><comment><author>masklinn</author><text>&amp;gt; you can simply JOP to one of the authorized syscall instructions and entirely defeat the mitigation&lt;p&gt;But now you need to know where the libc is mapped in order to find those syscalls instructions yeah? Which increases the complexity of the exploit, because instead of making a syscall you have to find where the libc is mapped, and the entire point of ASLR is making that difficult, no?</text></comment>