--ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On May 23, 2014 07:53 PM +0000, Wojciech A. Koszek wrote: > On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote: > > Hey All, > >=20 > > [NOTE: crossposting between freebsd-current@, freebsd-security@, and > > freebsd-stable@. Please forgive me if crossposting is frowned upon.] > >=20 > > Address Space Layout Randomization, or ASLR for short, is an exploit > > mitigation technology. It helps secure applications against low-level > > exploits. A popular secure implementation is known as PaX ASLR, which is > > a third-party patch for Linux. Our implementation is based off of PaX's. > >=20 > > Oliver Pinter, Danilo Egea, and I have been working hard to bring more > > features and robust stability to our ASLR patches. We've done extensive > > testing on amd64. We'd like to get as many people testing these patches. > > Given the nature of them, we'd also like as many eyeballs reviewing the > > code as well. > >=20 > > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on > > the RPI), when a parent forks a child, and the child gracefully exits, > > the parent segfaults with the pc register pointing to 0xc0000000. That > > address is always the same, no matter the application. If anyone knows > > the ARM architecture well, and how FreeBSD ties into it, I'd like a > > little guidance. > >=20 > > I also have a sparc64 box, but I'm having trouble getting a vanilla > > 11-current system to be stable on it. I ought to file a few PRs. > >=20 > > You can find links to the patches below. > >=20 > > Patch for 11-current: > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current= -aslr-segvguard-SNAPSHOT.diff > >=20 > > Patch for 10-stable: > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-= 10-aslr-segvguard-SNAPSHOT.diff > >=20 >=20 > Shawn >=20 > I appreciate you working on this. We must have this in FreeBSD. >=20 > I looked at the patch and I read, but not run it. Comments below. >=20 > My personal opinion is that kern_pax.c should be compiled in by default. = If > it adds a lot of size, it'd be better to provide empty stub calls instead= of > #ifdef'ing everything. But security is very important especially in > embeddded systems, so you can imagine you're writing the code that everyb= ody > wants and must have enabled for decent level of security. >=20 > All modern systems run with ASLR turned on. >=20 > I skipped user-space stuff. I don't think it's necessary in this commit a= nd > should be separated. >=20 > There's a lot of lines of code for status showing. Not sure if we care th= at > much: ASLR is either on or off. Not sure about more granularity. More bel= ow. We provide the level of granularity because there are a lot of applications that might exhibit weird behaviors or even crash if we randomize too many bits. We provide sane defaults, but allow each user to choose the level of security versus the level of stability they desire. >=20 > Lots of files: >=20 > You conditionally make .sv_pax_aslr_init method point to something else. = I'd > assume PAX function _pax_aslr_init32() always gets called and based on > whether ASLR is on or not, it does something or not. This will simplify t= he > code a lot, and the difference probably won't be measurable. >=20 > You have: >=20 > int a; > int b; >=20 > instead of: >=20 > int a, b; >=20 > And you miss spaces around "=3D" sometimes. Cleaning up the code and make style changes are a high priority on my list. Once I get a few more pieces of code locked down, I'm going to go over every line with a comb to make sure I'm adhering to the FreeBSD coding style. des@ has made a lot of suggestions in that regard and has even provided me with a sample vimrc. Prior to talking with des@, I was re-using the same vimrc that I use for ClamAV (which, admittedly, has a much different coding style than FreeBSD). >=20 > kern_jail.c: >=20 > something looks wrong here. Sounds like you need "pr->pax". But I don't > understand why you need to have these pr_* values here. It seems > unnecessary. I've made it possible to have per-jail ASLR settings. If you have an application that misbehaves, you can jail it with ASLR turned off just for that jail. My BSDCan presentation talks about this. The recording isn't up, yet, though. >=20 > kern_pax.c: >=20 > I can't quickly tell what locking is using. Some ASSERTS() in pax_ functi= on > would help. >=20 > pax_aslr_active(): >=20 > I don't see why you need to pass "td" and "proc" (I looked at usage: you > pass proc only once). I think you could always pass proc to it, with > td->td_proc passed typically. > kern_pax_*: >=20 > There's so many SYSCTLs I think people will have problem configuring it. > Pick reasonable value for all values and let users change them via > SYSCTL_INT (static sysctls) only for debugging. There are quite a few SYSCTLs, I agree. I'll talk with Oliver Pinter, one of the developers that is working with me on this ASLR implementation, to see if we can simplify this. >=20 > I can imagine we won't want ASLR only temporarily, for ports which break = and > must be fixed. So we probably just need per-process ASLR on/off switch an= d a > wrapper which could be used like: >=20 > aslr off program .... So we have right now an addition to mac_bsdextended(4)/ugidfw(8) that does this exact thing. We also plan on adding FS extended attribute support soon, too. Also, per-jail ASLR settings. >=20 > The debug stuff I'd remove too. We could have additional CTR stubs used > there, if necessary. Oliver just released a new patchset today with new debugging functionality. I'd love to hear your commments on it. >=20 > segvguard part I didn't understand. Why do you keep a list of programs th= at > failed? There was no ASSERTs, thus it was hard to understand the locking > too. We've semi-paused development of segvguard for the moment to focus on ASLR. Though the features are related and segvguard is recommended for a proper ASLR implementation, it is not required. Danilo Egea Gondolfo is the principal engineer behind our segvguard implementation. We're still working out the kinks and the underlying design and architecture of this feature. >=20 > I'm trying to understand if randomization is done correctly. Do you think > you could post the results? >=20 > Program: >=20 > http://pastebin.com/XTRHLhMg My results on an amd64 VM are pasted here: http://ix.io/cD5 We're in talks with des@, kib@, and Alan Cox regarding how our implementation could affect the VM system, with special consideration to superpages. Thanks for taking the time to read through the code and offer insight. One of the things we need to do is write documentation regarding our implementation. Both Oliver and I have wiki accounts and we've created the start of the documentation there. I think if we had better documented our implementation, there would've been less confusion on the part of those reading/analysing our code. wiki page: https://wiki.freebsd.org/Hardening Thanks, Shawn --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTf+lMAAoJEGqEZY9SRW7uq0gP/0clziBh6ejNHvFKkfejVAMz QGdqWilb3ptuOOLO3ujK0LVr1OJDdaIHxPQVQj2/fZ4yvDGjX6WK2/wUyjUsWbsr AzF2oGibPTLLBVkz7PEbJ9owrqEXU4e8AwVD7MWTTOI1vIU+Cw1i5NKyxhMiFMng dcF1/9Ym2TzZfX7WBquqA+7eb3AeHDc0JlpAE6P9F1tvPgKpukHYyDn7NBBXxXZS MOXQsws6Y7XmiJIjqTKV39sENcepPA44wEDBWgGWbjR9D2Y8ukxdOC3Fn9xMfFfE 4DbqvNB4prkK8xjtwuF1J14aqqQxWcKBP1gDOXCzcVXjZZXfmF0RZDPhDMhy7eKN kJbvfJYV0IyMqCw8+zvnFYATco4a1Pmux+jF3XWhQNcykrl8a7Iy4NLPrw2tJKa8 QAA9H/UE/Rg8QCp2vdo5dsyujo6hkh1Onq/vOHzTZHHrt6fo8ynTLkdefALttbt+ FZ8AF3arKB1ne9Amu2IqmEz38glpZCra5y9+QNf/0IHIlNWiym4q8ysTsPMGGaMP 1sXK3oQ2M+BP+2gEnAzLOAdJCzGMpR/Km7sm56/1olfr1aauG7cMdrvUdqRXpRG7 b0XMOosWJbGBS6kyibpbZjVrsKNul7LEA5FK1xLTzPMNSkE+Cu35kLUQKhJckQEd H3yLsGXKY1xhUcZG/PCx =bR7+ -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT--