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 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: https://www.youtube.com/watch?v=YYf1U0xcHmk 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 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 here ** 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 wdfree...@acumensecurity.net http://www.acumensecurity.net -----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 kern.stackgap_random=16777216 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 16777216 increases security? ====================================== 2) Can we have the cc-memtest binary or source? Or it is not public. http://blog.acumensecurity.net/revisiting-wx-with-openbsd-6-0/ ====================================== 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 > > -----BEGIN PGP SIGNED MESSAGE----- > 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/> > > -----BEGIN PGP SIGNATURE----- > > iQFRBAEBAgA7BQJX+6daNBxXaWxsaWFtIERlYW4gRnJlZW1hbiA8d2RmcmVlbWFu > QGFjdW1lbnNlY3VyaXR5Lm5ldD4ACgkQrnqwKenh3fRbrQgAjFsvyXA6bZIPYyjX > 0A3ldKlFTekRuyFnhmWuX3CsK5eV7azrADyamuPV5T2YMN7U0tmjcOC9hOX3OPsK > 0IC9YqTjGxpLuxt0Z7GeXeeRO58SvroKMbsKZz6pU8pvKAJn8Hl/0UcAJsmfcHUd > 6ErH7wuHgpCEzTHGkiEIz1W/kPZXUsRhT9XpURUCBwOp01vsl5Lm9GfYWb64zHCM > f9fDwkasE/Dy8amn907bGLSP1M711HhVB5cP76xe0twYyxOKtNRlJno2Kc9cEr4D > d2U/r/iCG8A9Qabp+QBuxVWTdP3kq2LwDqb6ySUSLLrSYLbRjUOi+7GhQer3yM+r > 6TEFcQ== > =gBZh > -----END PGP SIGNATURE----- [demime 1.01d removed an attachment of type application/pkcs7-signature]
