if anyone interested, correction for the pax topic Sent: Tuesday, October
11, 2016 at 3:57 PM
From: "W. Dean Freeman" <wdfree...@acumensecurity.net>
To: "'Peter Janos'" <peterjan...@mail.com>
Subject: RE: RE: OpenBSD PaX Test questionIncreasing 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
top of a new stack frame, so that when an attacker is analyzing a binary
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
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,
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,
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
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
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 basic tests:
1. Attempt to mmap(2) a page of memory with permissions
** 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
mapped buffer, then write a function pointer to it and attempt to execute
order to cause a page fault there and record the violation is caught
proving that I didn't get W|X memory
2. attempt to map a page of memory as writable then mprotect() to W|X.
PaX, the page stays writable. OpenBSD will abort the processes here
** I did share a version with Red Hat through technical community
which included proof via live shell code that even if you turn off
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
Again, OpenBSD will abort this but PaX just gives you back what you had

I may be able to share the tool, but it basically just does a subset of
is in the paxtest, geared directly at three sub-cases for one security
functional requirement which isn't even mandatory right now. However,
didn't want to burn political capital with the Linux kernel devs pushing
it when OpenBSD didn't even turn it on. Now that they have, there may be
better case to be made in that regard.

W. Dean Freeman, CISSP, CSSLP, GCIH
Lead Security Engineer
Mobile: +1.8048158786

-----Original Message-----
From: Peter Janos [mailto:peterjan...@mail.com]
Sent: Tuesday, October 11, 2016 2:23 AM
To: W. Dean Freeman <wdfree...@acumensecurity.net>
Subject: Re: RE: OpenBSD PaX Test question

Only two question:


1) Increasing kern.stackgap_random=262144 to
increases the "14 quality bits" to "20 quality bits".

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
increases security?


2) Can we have the cc-memtest binary or source? Or it is not public.


Many Thanks!

> Sent: Monday, October 10, 2016 at 5:46 PM
> From: "W. Dean Freeman" <wdfree...@acumensecurity.net>
> To: "'Peter Janos'" <peterjan...@mail.com>
> Subject: RE: OpenBSD PaX Test question
> Sure, go ahead.
> From: Peter Janos [mailto:peterjan...@mail.com]
> Sent: Monday, October 10, 2016 11:46 AM
> To: W. Dean Freeman <wdfree...@acumensecurity.net>
> Subject: Re: OpenBSD PaX Test question
> can I post this as an anser on stackexchange?
> Thank you!
> Sent: Monday, October 10, 2016 at 4:36 PM
> From: "W. Dean Freeman" <wdfree...@acumensecurity.net
> <mailto:wdfree...@acumensecurity.net> >
> To: peterjan...@mail.com <mailto:peterjan...@mail.com>
> Subject: OpenBSD PaX Test question
> Hash: SHA1
> Hi Peter,
> I'm the author of the blog post that you referenced in your stack exch
> ange post.
> As you may note from the blog post, I make three points in particular:
> 1. 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.
> 3. 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
> s.
> 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.
> Thanks,
> Dean
> - -----
> W. Dean Freeman, CISSP, CSSLP, GCIH
> Lead Security Engineer
> Mobile: +1.8048158786
> wdfree...@acumensecurity.net <mailto:wdfree...@acumensecurity.net>
> <mailto:wdfree...@acumensecurity.net>
> http://www.acumensecurity.net <http://www.acumensecurity.net/>
> iQFRBAEBAgA7BQJX+6daNBxXaWxsaWFtIERlYW4gRnJlZW1hbiA8d2RmcmVlbWFu
> QGFjdW1lbnNlY3VyaXR5Lm5ldD4ACgkQrnqwKenh3fRbrQgAjFsvyXA6bZIPYyjX
> 0A3ldKlFTekRuyFnhmWuX3CsK5eV7azrADyamuPV5T2YMN7U0tmjcOC9hOX3OPsK
> 0IC9YqTjGxpLuxt0Z7GeXeeRO58SvroKMbsKZz6pU8pvKAJn8Hl/0UcAJsmfcHUd
> 6ErH7wuHgpCEzTHGkiEIz1W/kPZXUsRhT9XpURUCBwOp01vsl5Lm9GfYWb64zHCM
> f9fDwkasE/Dy8amn907bGLSP1M711HhVB5cP76xe0twYyxOKtNRlJno2Kc9cEr4D
> d2U/r/iCG8A9Qabp+QBuxVWTdP3kq2LwDqb6ySUSLLrSYLbRjUOi+7GhQer3yM+r
> 6TEFcQ==
> =gBZh

[demime 1.01d removed an attachment of type application/pkcs7-signature]

Reply via email to