[HN Gopher] SerenityOS: Writing a Full Chain Exploit
       ___________________________________________________________________
        
       SerenityOS: Writing a Full Chain Exploit
        
       Author : ingve
       Score  : 71 points
       Date   : 2021-02-12 16:09 UTC (6 hours ago)
        
 (HTM) web link (devcraft.io)
 (TXT) w3m dump (devcraft.io)
        
       | jandeboevrie wrote:
       | SerenityOS is an amazing project. Great videos, fun and
       | interesting to watch and the os itself is surprisingly usable.
       | Great example of modern C++.
        
         | mouldysammich wrote:
         | I think the whole project is just so fun. I contributed a
         | couple of patches and the whole community behind it is so warm
         | and welcoming. Its incredibly pleasant and refreshing to
         | interact with.
        
       | yannoninator wrote:
       | Looks like a lot went into this, i'm sure you must have been paid
       | for your efforts with a bounty right?
        
         | olliej wrote:
         | I believe Andreas does $5 bounties
        
           | akling wrote:
           | I certainly do! http://serenityos.org/bounty/ :^)
        
       | breckinloggins wrote:
       | Serenity is a great community to keep up with if you're
       | interested in OS security (along with a whole lot of other topics
       | that are typically buried in decades of incidental complexity).
       | 
       | There are a number of things in this exploit you can no longer do
       | in latest Serenity:
       | 
       | 1. As the author mentioned, the entry point of this chain is
       | fixed (the specific overflow problem in JSLib).
       | 
       | 2. User libs have ASLR (edit: this used to say the kernel has a
       | slide, but this is incorrect).
       | 
       | 3. You can no-longer mprotect with PROT_EXEC after you create a
       | writeable page (W^X)
       | 
       | 4. This may or may not be relevant, but there is now a "blessed
       | syscall pages" feature, preventing anyone except libc^h^h^h^h
       | libSystem.so and a couple of other places from directly invoking
       | syscalls, so you better find a few pages from libSystem or it
       | will be a whole lot harder to reach out and touch someone with
       | your exploit.
       | 
       | (Andreas and crew went on a month-or-so long security trek after
       | a few CTFs and these changes plus quite a few others were the
       | result.)
        
         | wbowling wrote:
         | Yeah a lot of work has happened in the few weeks since I
         | started looking at this!
         | 
         |  _The kernel has a slide_
         | 
         | Oh cool must have missed that, very nice :)
        
         | akling wrote:
         | Indeed, I've had a _ton_ of fun learning about system security
         | by implementing various protection mechanisms and security
         | mitigations (and doing some of my own exploits, too!) I 'm
         | learning new stuff all the time, so I've been growing the
         | system's defenses along with my own skills.
         | 
         | One small correction: the kernel does not yet have a slide, but
         | everything else is accurate. Also, the blessed syscall pages is
         | now down to a single page in in libsystem.so[1]
         | 
         | Furthermore, as of today[2] we also randomize the location of
         | JavaScript heap memory, which makes the spray technique used in
         | this exploit a lot less reliable as well :)
         | 
         | 1.
         | https://github.com/SerenityOS/serenity/commit/e87eac92730f1c...
         | 
         | 2.
         | https://github.com/SerenityOS/serenity/commit/e8d38567369253...
        
           | breckinloggins wrote:
           | Thanks Andreas. I've updated my comment to reflect those
           | corrections.
        
       ___________________________________________________________________
       (page generated 2021-02-12 23:01 UTC)