if anyone interested, correction for the pax topic
Sent: Tuesday, October 11, 2016 at 3:57 PM From: "W. Dean Freeman"
To: "'Peter Janos'"
Subject: RE: RE: OpenBSD PaX Test question
Increasing the stack gap size isn't necessarily bad or good.
Basically, you're adjusting the run-time value of a gap page that gets
inserted at the top of a new stack frame, so that when an attacker is
analyzing a binary and attempting to write an exploit, there is an
unknown-at-compile-time number of bytes which have to be included when
building the exploit and attempting to over-write the return address
to the previous stack frame. It's just one of a series of mitigations
against buffer overflows (like stack canaries, W^X, etc. You're also
here adjusting the amount of room there is to play with when
randomzing addresses for ASLR, at least as is my understanding.
So, I doubt it hurts anything, but given the general strength of ASLR,
stack gaps, stack cookies, the new W^X feature, etc. I'm not sure it's
really necessary. If you really want to play with something fun that
may ferret out bugs either in your code or in things you get from
ports, turn on memory junking in the /etc/malloc.conf. For a
discussion on some fun around that, see here:
To the second question, there isn't any magic to what I'm doing in
that program and between screenshots from GDB and a description of
what's going on, you should be able to reconstruct it. There are three
1. Attempt to mmap(2) a page of memory with permissions PROT_WRITE|PROT_EXEC
** on OpenBSD, this will cause the program to abort. On HardenedBSD or NetBSD, you'll get a writable page of memory back
** If you get the page back, I put a bit of do-nothing shell code into the mapped buffer, then write a function pointer to it and attempt to
execute in order to cause a page fault there and record the violation
is caught properly, proving that I didn't get W|X memory
2. attempt to map a page of memory as writable then mprotect() to W|X. With PaX, the page stays writable. OpenBSD will abort the processes
** I did share a version with Red Hat through technical community channels, which included proof via live shell code that even if you
turn off execmem allocation in SELinux, that you get no protection
around mprotect and can still get a shell here.
3. Attempt to map a page of memory as executable and then mprotect() to W|X. Again, OpenBSD will abort this but PaX just gives you back
what you had originally
I may be able to share the tool, but it basically just does a subset
of what is in the paxtest, geared directly at three sub-cases for one
security functional requirement which isn't even mandatory right now.
However, RedHat didn't want to burn political capital with the Linux
kernel devs pushing for it when OpenBSD didn't even turn it on. Now
that they have, there may be a better case to be made in that regard.
----- W. Dean Freeman, CISSP, CSSLP, GCIH Lead Security Engineer Mobile: +1.8048158786 firstname.lastname@example.org
-----Original Message----- From: Peter Janos [mailto:email@example.com] Sent: Tuesday, October 11, 2016 2:23 AM
To: W. Dean Freeman Subject: Re: RE:
OpenBSD PaX Test question
Only two question:
1) Increasing kern.stackgap_random=262144 to
kern.stackgap_random=16777216 increases the "14 quality bits" to "20
Stack randomization test (SEGMEXEC) : 20 quality bits (guessed) Stack
randomization test (PAGEEXEC) : 20 quality bits (guessed) Arg/env
randomization test (SEGMEXEC) : 20 quality bits (guessed) Arg/env
randomization test (PAGEEXEC) : 20 quality bits (guessed
is this a wise thing to do? Does setting the kern.stackgap_random to
16777216 increases security?
2) Can we have the cc-memtest binary or source? Or it is not public.
Sent: Monday, October 10, 2016 at 5:46 PM
From: "W. Dean Freeman"
To: "'Peter Janos'"
Subject: RE: OpenBSD PaX Test question
Sure, go ahead.
From: Peter Janos [mailto:firstname.lastname@example.org]
Sent: Monday, October 10, 2016 11:46 AM
To: W. Dean Freeman
Subject: Re: OpenBSD PaX Test question
can I post this as an anser on stackexchange?
Sent: Monday, October 10, 2016 at 4:36 PM
From: "W. Dean Freeman" >
Subject: OpenBSD PaX Test question
-----BEGIN PGP SIGNED MESSAGE-----
I'm the author of the blog post that you referenced in your stack exch
As you may note from the blog post, I make three points in particular:
- OpenBSD does not follow the PaX model (and therefor shouldn't be
expected to do everything that paxtest checks for, necessarily, and
certainly not in the same way) 2. In OpenBSD, you can still use
mprotect() To switch between wri table and executable pages of memory,
because what is enforced is stri ctly W^X, not W!->X.
- My claims about OpenBSD 6.0 were strictly in relation to the c
onformance with FPT_W^X_EXT.1 in the latest revisions of the NIAP-appr
oved Operating System Protection Profile for Common Criteria.
So, an operating system like HardenedBSD or NetBSD, which follow the P
aX model, will not allow you to successfully do something like this:
* Map a page of memory as writable
* Subsequently mprotect() that page to W|X
* OR mprotect() that page to just X after it was W
On OpenBSD, the behavior is:
* You cannot map a page of memory W|X
* You cannot mprotect(2) a page of memory that is W to W|X
* You can map a page of memory as, say, R|W, then mprotect(2) t o R|X
This allows you to, say, run new Firefox builds, which use this mprote
ct(2) swapping method to keep pages allocated by the JIT from being W|
X at the same time without having to push Firefox off onto a separate
/opt filesystem or something where you have fs flags to remove the W^X
protections. In HardenedBSD or NetBSD you would still have to use se
cadm or paxctl to remove the mprotect hardening on a per-binary/per-pr
ocess basis because the PaX model wouldn't let you swap the permission
I demonstrated this in the blog post, towards the end, and then explai
ned why this matters in the context of JITs.
Please let me know if you have any other questions, but I hope this he
lps clear it up. Essentially, your'e going to get those "vulnerable"
messages from the pax test tool because OpenSBD doesn't do PaX.
W. Dean Freeman, CISSP, CSSLP, GCIH
Lead Security Engineer
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----