On Thu, Jan 15, 2026 at 11:03:48PM -0500, David Higgs wrote:
> On Thu, Jan 15, 2026 at 2:28 PM <fro@disciples.com> wrote:
>
> > It looks like the author of these has posted an updated POC of the W^X
> > break script since the start of this thread.
> >
> > Here:
> > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/107#note_47812
> >
> > Quoting, they say this:
> >
> > "I have seen on openbsd-misc that people are rightfully claiming this
> > break does not work on OpenBSD due to pinsyscalls. That said, this is only
> > because I was lazy when writing the poc, this break has otherwise nothing
> > to do with pinsyscalls. Also note this break works regardless of whether
> > the executable memory was mapped MAP_PRIVATE or MAP_SHARED. Below is an
> > update poc that pops a shell despite pinsyscalls on OpenBSD using a simple
> > libc trampoline"
> >
> > I can also confirm that this works as they say.
>
>
> The first, previously-linked example does not make any syscalls between the
> two stack pivots. MAP_STACK is enforced at the kernel syscall boundary.
> Note the "exploit" didn't work when it made a printf (write) call after
> only one stack pivot.
>
> The second example demonstrates lazy-loading of file-backed mmap content.
> Pinsyscalls is not involved because all syscalls are still made through
> libc. Note the file is truncated before the mmap. What do you think is
> present in the mmap'd buffer before the write+close?
>
> There is no privilege escalation in either case. The burglar is already
> inside the house.
> https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283
Hey David,
I can't seem to find where the original author (Ali Polatel) claimed
his techniques were that of a privesc nature. Can you point me to
where privilege escalation was claimed by the original author?
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Signal Username: shawn_webb.74
Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
No comments:
Post a Comment