[HN Gopher] 0x01 - Killing Windows Kernel Mitigations
       ___________________________________________________________________
        
       0x01 - Killing Windows Kernel Mitigations
        
       Author : neilwillgettoit
       Score  : 113 points
       Date   : 2024-12-08 01:14 UTC (6 days ago)
        
 (HTM) web link (wetw0rk.github.io)
 (TXT) w3m dump (wetw0rk.github.io)
        
       | wetw0rk wrote:
       | If you're following my Windows Kernel Exploitation series the
       | time to bypass modern mitigations is now.
       | 
       | We've learned how to exploit a Stack Overflow in Windows 7 (x86)
       | but what has changed since then?
       | 
       | Truthfully a lot, but the core fundamental problem exists and as
       | such we as hackers will always find a way to exploit them.
       | 
       | As part of this tutorial, I will be releasing my technique on
       | bypassing SMEP and VBS I have dubbed Violet Phosphorous. I
       | personally have not seen these mitigations bypassed in this
       | manner so I'm claiming it.
       | 
       | To prove its effectiveness, I installed the latest Windows 11
       | (x64) build (24H2) and successfully elevated my privileges to NT
       | AUTHORITY/SYSTEM.
       | 
       | The king is dead, long live the king!
       | 
       | LONG LIVE THE STACK OVERFLOW!
        
         | dang wrote:
         | (This text was originally part of
         | https://news.ycombinator.com/item?id=42353276 but that got
         | killed by HN's software (bad), so I moved it here to the live
         | post.)
        
         | daneel_w wrote:
         | Was your test install also fully updated, i.e. is your exploit
         | currently valid?
        
           | wetw0rk wrote:
           | Yes the violet phosphorus technique works on the default
           | configuration of the latest build :)
        
         | cahoot_bird wrote:
         | Super interesting. At one point thought control flow guard +
         | DEP/ASLR was suppose to prevent this stuff, guess it can't be
         | prevented nearly completely by now. Sounds like this took a lot
         | of work to figure out, well done.
         | 
         | Any comment on reporting to Microsoft or perhaps motivation for
         | this research?
        
           | anyfoo wrote:
           | So called "post-exploit" mitigations are practically always
           | only hardening, i.e. making subsequent attacks harder (and
           | fewer). Ideally much harder. But if you want an absolutely,
           | provably (within limits, i.e. halting problem etc.) secure
           | system, you have to eliminate bugs that can lead to any
           | exploitable situations beforehand. In this case for example,
           | that would mean no situation existing that could cause a
           | buffer overflow in the first place. Memory-safe languages
           | help for this case.
           | 
           | Obviously this is hard, so post-exploit mitigations will
           | likely continue to still make things harder for attackers for
           | quite a while at least.
        
             | snvzz wrote:
             | Capabilities (as implemented in e.g. seL4) is the way to
             | go.
        
         | wswope wrote:
         | Gonna have to give it a proper read-through over the weekend,
         | but this looks like a stellar guide at a glance. Sincere thanks
         | for sharing your work and looking forward to further entries in
         | the series!
        
           | wetw0rk wrote:
           | Thank you!
        
         | snvzz wrote:
         | >LONG LIVE THE STACK OVERFLOW!
         | 
         | The mitigation known as Shadow Stack might have something to
         | say here.
        
       | gavinray wrote:
       | Expect game cheat developers to adopt this within the week.
        
       | MortyWaves wrote:
       | It's good that it is so well written so that Microsoft know how
       | to fix it
        
       ___________________________________________________________________
       (page generated 2024-12-14 23:02 UTC)