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.
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.)
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 :)
SerenityOS is an amazing project. Great videos, fun and interesting to watch and the os itself is surprisingly usable. Great example of modern C++.
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.
Looks like a lot went into this, i'm sure you must have been paid for your efforts with a bounty right?
I believe Andreas does $5 bounties
I certainly do! http://serenityos.org/bounty/ :^)
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.)
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 :)
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...
Thanks Andreas. I've updated my comment to reflect those corrections.