On Fri, May 23, 2014 at 08:35:25PM -0400, Shawn Webb wrote: > 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, > > > > > > [NOTE: crossposting between freebsd-current_at_, freebsd-security_at_, and > > > freebsd-stable_at_. Please forgive me if crossposting is frowned upon.] > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > You can find links to the patches below. > > > > > > Patch for 11-current: > > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff > > > > > > Patch for 10-stable: > > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff > > > > > > > Shawn > > > > I appreciate you working on this. We must have this in FreeBSD. > > > > I looked at the patch and I read, but not run it. Comments below. > > > > 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 everybody > > wants and must have enabled for decent level of security. > > > > All modern systems run with ASLR turned on. > > > > I skipped user-space stuff. I don't think it's necessary in this commit and > > should be separated. > > > > There's a lot of lines of code for status showing. Not sure if we care that > > much: ASLR is either on or off. Not sure about more granularity. More below. > > 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. I'm OK with it being more granular if that's the case. But Linux/MacOSX all have ASLR. If we have programs in ports/ that run on Linux, it's likely they'll just work. If they break, we'll just marked them as broken and to be fixed by the maintainer. Can you run GNOME or KDE with your patch? Or node.js? Node.js uses JIT engine for Javascript. If it works, it's quite likely other will work. > > > > kern_jail.c: > > > > 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. I don't get it. If there's a program that is broken but you want to run it in jail, our rc.d jail startup script should earn a "NOPIE" function maybe. I believed PIE/NOPIE is per-process setting on whether to use PIE or not. In this case we'd be able to do: /usr/sbin/jail ...... /usr/sbin/nopax program ... In Linux you can do it with personalities. I don't know what it would translate in the FreeBSD to. I guess this could be achieved with simple per-process SYSCTL. "nopax" would disable ASLR, fork and exec(). > > 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 and a > > wrapper which could be used like: > > > > 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. If you can already do it with MAC layer, it should be enough. Touching jail(8) will require lots of people to review this patch and analyze it in a great details, which typically slows things down a lot. > > 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. Like des_at_ and David said: I'd just use ktrace/audit subsystem. > > > > segvguard part I didn't understand. Why do you keep a list of programs that > > 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. What is it for? What does it do? I'd remove it until you get basic ASLR in the kernel. > > I'm trying to understand if randomization is done correctly. Do you think > > you could post the results? > > > > Program: > > > > http://pastebin.com/XTRHLhMg > > My results on an amd64 VM are pasted here: http://ix.io/cD5 > OK, so the comparison for stack is: MacOSX : 0xfffff000 20 random bits Linux : 0xfffffff0 28 random bits FreeBSD: 0x000ffff0 16 random bits Could we make FreeBSD be like Linux? Heap randomization also looks better on Linux. Thanks for preparing it. -- Wojciech A. Koszek wkoszek_at_FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/Received on Fri May 30 2014 - 22:43:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:49 UTC