David, Steve, While I appreciate your comments on this I'm not sure either of you are understanding this very well. Neither of these are exploits or meant to escalate privileges. They are literally just doing exactly what the author described them to do and nothing more.
However, they could be used in an exploit chain to bypass these mitigations. I think my understanding is you're both saying that these mitigations are not meant to mitigate these specific issues and that's fine but let's not move the goalposts from where they are. Respectfully, fro > Sent: Friday, January 16, 2026 at 9:10 AM > From: "Shawn Webb" <[email protected]> > To: "David Higgs" <[email protected]> > Cc: [email protected], [email protected] > Subject: Re: Stack pivot, W^X break > > On Thu, Jan 15, 2026 at 11:03:48PM -0500, David Higgs wrote: > > On Thu, Jan 15, 2026 at 2:28 PM <[email protected]> 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 >
