Introducing ASLR in FreeBSD
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Webb, Shawn
Address-space layout randomization (ASLR) has existed in many operating systems for a number of years. The most famous implementation is the PaX patch for Linux's kernel. This presentation introduces and announces an ASLR implementation based on PaX for FreeBSD/amd64. Details regarding how ASLR has been ported to FreeBSD and some advanced features will be presented. FreeBSD will soon be getting a port of PaX to 11-CURRENT/amd64. This presentation details changes to how ELF executables are loaded in memory and innovative workarounds for legacy applications that don't support (or misbehave) ASLR. Jails can have their own ASLR settings. Misbehaving applications can be run in a jail with ASLR turned off, while ASLR remains turned on in the other jails and in the host.
 We've got quite a few projects underneath us and ASLR is one of the projects that we took on. And while people are joining in, while people are still filing in, I thought I would have a little egotistical moment and talk a little bit about me. I'm a big fan of open source. When I started learning how to program, when I was like 12 or so, I didn't even have a computer. I wrote in C on like a piece of paper or anything. It really sucked. And so did my code. But I'm a big fan of open source. When we got a computer and I finally got online, I would look at other people's source code and learn from others. That was a big help. I love freeBSD and ZFS. Great technologies in freeBSD. ZFS is amazing. I'm such a fanboy of ZFS that I even have it running on my little netbook, which kind of sucks. Makes it a little bit slow, but it works. I'm passionate about security. The first time I got online, I was like 14. And I spent a whole month convincing my parents that we need a 56k dial-up modem. And we got online using that free trial of AOL. And then I found out about NetZero and Juno. So NetZero and Juno, they provide free dial-up service, or they did at the time. But they made it so that you had to install Adware on your system. So it would be a program that displays just a little rectangular image with ads. I'm like, dude, this takes up a lot of my precious dial-up bandwidth. I can't deal with this. And so my first experience with security was downloading a hex editor and looking at how the strings and stuff, how the dial-up program authenticated and grepping through using strings to look at all the 800 dial-up numbers. So we didn't have to call long distance either. And so I found out what numbers it uses and how it authenticates with their servers. And I ended up scripting my own little dial-up connection clients so that I wouldn't have to use their Adware. So that was pretty fun. I've submitted a few patches to FreeBSD. By far, ASLR is the biggest. I'm a maintainer of a few FreeBSD ports, mainly dealing with jails and Go and Drupal. I'm the author of Libhijak. Dude, I remember you. That's not necessarily good. I spoke last year about it. It's a tool that makes a shared library that makes runtime process infection easy on Linux and FreeBSD. It's a pretty cool tool. You can inject shell code in as little as eight lines of C code. It's pretty nifty. One of my friends right now is porting it to ARM for Linux. So eventually, hopefully, we'll use Libhijak for a lot of security things on Android devices. A little bit of a disclaimer. Of course, I have to put this to satisfy the legal department. Any opinions, thoughts, ideas, tools, blah, blah, blah, they reflect me only. And SoldierX, not any of my previous employers, my current employers, or future employers. So I'm here on my own accord. I am representing SoldierX here today because they've donated hardware to the project. They've donated resources. They're pretty cool peeps. So what we're going to do is we're going to start off with a few definitions. We're going to start off, you know, try to get on the same page with what ASLR is and the history behind it. Then we're going to talk about FreeBSD security strengths and their weaknesses, some of the things that need to be improved upon. And then we're going to talk about what we can learn from others because FreeBSD is pretty much the last enterprise operating system to implement ASLR. And so we have the unique opportunity to learn from the strengths and mistakes of others. Then I'm going to talk about how we've implemented ASLR in a very kind of high level detail because I've only got 45 minutes. In ASLR, ASLR touches quite a few different places in the system. In the source code, I don't have the time to go in depth. But I'm at least going to show you the files that are modified and what we do. Then I'm going to talk about how to use ASLR in FreeBSD and what needs to happen next. Then I've got a live demo and I did sacrifice 3.5 goats to the demo gods. And the goat BOF was born. So for definitions, security, it's what Sony and Mt. Gox have in common. They suck at it. Really, security is just an onion that's made up of ever increasing layers. And the more layers you have, the more time and resources it's going to take an attacker to successfully exploit your system. So we have many different layers. One of those layers are different exploit mitigation technologies, techniques. An exploit mitigation technique is a method or technique to prevent the successful exploitation of security vulnerabilities. Our computers have millions and millions and millions of lines of code in them. All these programs, dozens of programs, hundreds of programs we run on our computer. We don't know where the vulnerabilities lie. But an attacker, a dedicated attacker is going to use whatever means possible to pop a shell on your box. And so exploit mitigation technologies allow you to secure your system from the unknown. At least help in giving you more time to be able to address security vulnerabilities. ASLR is one such exploit mitigation technology. It is address based layout randomization. So what happens is, without ASLR, your application that you want to run like Firefox, for example, says to the operating system, I expect to be loaded at this address. My data is here. I need it here. If it's not here, I'm going to crash. And so your program is loaded in a deterministic way. So if there's a vulnerable function, if there's a piece of data that an attacker is interested in, either a vulnerable function or a password stored in memory, a social security number, credit card number, whatever it is, then the attacker knows exactly how to reach that point in memory and trigger that vulnerability. What ASLR does is it randomizes where the program and its dependencies are loaded in memory. So the attacker doesn't know, the attacker knows that there is a vulnerability, but he doesn't know where in memory it is. So the program like Firefox, I was saying, for example, will tell the operating system, hey, I can be loaded anywhere in memory. That's fine. My data can be loaded anywhere in memory. I'll make do. You just tell me where I'm loaded and we'll make amends. So ASLR helps protect against very low-level attacks, buffer overflows, return to libc, and when you mix that with full format string vulnerabilities and integer overflows. So really low-level things. ASLR doesn't help protect against PHP, LFI, and RFI, and SQL injection attacks and cross-site scripting, all that fun stuff. That's too high-level for ASLR. So we're really just talking about really low-level vulnerabilities here. You can think of exploits like Stuxnet and Flame and even Heartbleed, even though ASLR wouldn't have helped in the Heartbleed case, but same kind of low-level type of thing. To give a little bit of history, this is all on Wikipedia, so thanks Wikipedia University. Just to get on the same page, though, in 2001, we now know that the PAX team is just a single person, but at the time we didn't know if it was one person or multiple people. So I still call them the PAX team just because that's how we've called them over the years. They implemented as a third-party patch ASLR for Linux. And in 2004, OpenBSD picked up that patch and it took open... You didn't know about it. Oh, you didn't? It wasn't in any of them. Oh, okay. Sorry. Well, then that was wrong. Well, in 2004, OpenBSD started implementing ASLR. I think it, I guess, maybe not based on PAX, but at least their current implementation is based on PAX, I believe. No? Really? Okay. All right. It may have been based on the same research. Okay. But none of the code. None of the code. None of the code. I don't think of any of the better papers. Okay. All right. Well, I learned something new every day. So it took OpenBSD four years to implement ASLR, but to their credit, they had a lot more work to do. They had to change a whole lot of stuff in order to support ASLR because we're coming at this a little bit behind. We don't have to change as much stuff. There's not a lot, not as many prerequisites for implementing ASLR. For us, it's already been done. In 2005, Linux ripped PAX's ASLR and they dumbed it down, called it more secure, and did a lot of politics bull crap there. I'll talk a bit about more about Linux and I know I learned from others' slide. In 2007, Microsoft introduced ASLR into Windows Vista. Their initial ASLR implementation was crap. Very easy to bypass, extremely easy. It was pretty much useless. They made some design and architecture decisions that were more of a mistake that last till today because they had to add some fields to the PE header to say, we'll talk about that later. They introduced ASLR in 2007. It took Apple five years to finish up their ASLR work for OS 10, which they started in 2007. In 2011, Sun or Oracle, I don't remember what year Oracle bought Sun, but they introduced ASLR into Solaris 11. In 2014, Oliver Pinter and I submitted call for testing emails to the mailing list for our ASLR implementation on FreeBSD. FreeBSD has a lot of security strengths. FreeBSD's security mainly relies on policy-based security decisions. The Mac framework, NFSV4 and Post-6 ACL, secure level, auditisty and jails. You can think of jails and beehive as sort of a policy-based security because you're saying that I don't trust this application so I'm going to jail it. FreeBSD has kind of a hybrid policy-based and exploit mitigation technology, sandboxing, known as Capsicum. That's a pretty good implementation. Sandboxing is pretty cool. I don't have that listed on the slide. I forgot to put it, but Capsicum seems to be pretty useful, pretty promising for the future. Non-policy technology. These are exploit mitigation technologies, non-exec stack for AMD64 and P-Trace restrictions. Fun little fact is the P-Trace restriction prevents lib hijack from working. FreeBSD does have a few weaknesses. There were the non-exec stack. That means that you can put your shell code on the stack. When you're exploiting an application, your end goal is to run arbitrary code known as shell code. But you can store it on the stack. You're just not going to get it to run on the stack. FreeBSD has that, but it's not working on all platforms. I have a Raspberry Pi and supposedly it supports a non-exec stack, but it doesn't. Once we're finished with the ASLR patch itself, I'm going to go back and take a look and see why non-exec stack isn't being obeyed on ARM. One of the things that goes hand in hand with ASLR is called position independent executable support. I'm going to call that Pi because that's a lot easier to say than position independent executable. ASLR, really, to be effective, needs Pi support. That's the part that tells the operating system, that the program can be loaded anywhere in memory. For ASLR to be effective, Pi support needs to happen in base. I'm actually working on that right now and hoping to get a patch up to Brian Drury tonight to be merged into your head. That will be coming here soon. Of course, there's no ASLR in FreeBSD. That's why we're talking about it. GRSec is a third-party patch to the Linux kernel that hardens the kernel and the user land. My end goal is to port all the features that make sense for FreeBSD to FreeBSD. To learn from others, Linux is really political. It's a territorial pissing contest when it comes to this kind of stuff. What they did was they saw PAX's work, but they didn't want an implementation from an anonymous author. We didn't know. The Linux guys didn't know who wrote PAX's ASLR implementation. They wanted something of their own. Instead of trying to figure out who it was and contact them, there's an actual email address for them. They could have just emailed the guy. They ripped PAX's code and dumbed it down and called it more secure. The one thing that drives me to FreeBSD more than anything, I love FreeBSD's technologies, the one thing that drives me to FreeBSD over everything is the lack of politics. When it comes to this kind of stuff, I sat down with Desk the other day. I was kind of scared because this is the first time that I ever had a major patch review. I was kind of scared. It was more about the technology. He had some ideas and suggestions. It's more like, you've got a patch, that's cool. We need to get this in. But first, let's fix a few issues. It's more about the technology with FreeBSD than the territorial pissing contest. That's been my experience. Other people's experience may vary, but that's been my experience when submitting patches and helping out the FreeBSD project. It's not nearly as mind-numbing as it is with Linux. Technologically speaking, Linux is ASLR. I'm not going to talk about packs because Linux's actual ASLR implementation is pretty weak and pretty dumb. It's either turn ASLR on globally or turn it off globally. If you want this exploit mitigation technology on your system, but you have one application that is closed source, kind of like Flash or the NVIDIA binaries. What do you want to have ASLR for? If an application that is misbehaving under ASLR, like it's crashing or there's other bugs, then you have to have ASLR turned off for the whole system. That's stupid. The two things that I took away from this is that we need to randomize enough bits because that's the problem with Linux's AS. That's one of the problems with Linux's ASLR is that they're not randomizing enough bits. There's no way to control how many bits you want to randomize. There's no way to toggle it on a per application basis. That's kind of a half-lie, but not really. This command up there, that set arch right there, you have to use that command every single time you run this application that you want ASLR disabled for. It's kind of stupid. If you have an application that gets started via init scripts, you have to go and modify init scripts to disable ASLR. Every time you update the package for that, you have to back out your modifications, let the package update, and then reinsert your modifications. It's stupid. One of the things that I learned from Linux is we want to be more flexible and more dynamic than that. Windows, now with Windows 7, Windows 8, they have a pretty decent technical implementation. The biggest issue there is individual DLLs and EXCs can have ASLR turned on or off. In EXC, both EXCs and DLLs are just PE files. There is a bit inside of the PE file that says, for this object, ASLR is turned on or off. You can have an EXC that depends on, let's say, five DLLs, for example. We'll say the EXC has ASLR turned on and four out of the five DLLs have ASLR turned off. That means one DLL has ASLR turned off. The windows will apply ASLR to the EXC and to the four DLLs, and ASLR won't get applied to the one DLL. We'll be in this hybrid state where ASLR was applied but not. That is a big issue because, for example, just recently, I can't name the vendor, but there was one vendor who, if you use Windows, you probably use their software every day or nearly every day, especially if you're looking at documentation. They had just released a new version of their software and it depended on quite a few different DLLs. It was just that exact same scenario. They had compiled their applications with ASLR support and all the DLLs except for one. There was a vulnerability in one of the DLLs that had ASLR turned on, but the call stack was such that the control flow could be controlled via the DLL that had ASLR turned off. Because they could use that DLL that had ASLR turned off, because that was loaded in a deterministic way, attackers were able to successfully exploit the application using nothing more than just your standard exploitation techniques. That can be a major issue. We still have that kind of issue with the ELF file format on FreeBSD, but that's because the ELF file format was designed years and years and years and years way before ASLR was even thought of. That's why pie support is really important, because otherwise you're not randomizing all of the address space. If you don't have pie support for that application, you're still randomizing where the dependencies, the shared objects, get loaded, but not the binary itself. So you still kind of have that DLL issue just in reverse. So ASLR is available for FreeBSD, is available on all architectures FreeBSD supports with some... We don't have hardware for all architectures, of course, so your mileage may vary. We actively test on AMD64, i386 ARM, and kind of Spark64, vanilla FreeBSD, just FreeBSD11 current without the ASLR patches at all, has issues on Spark64, so I haven't been able to test the ASLR stuff too much on Spark64. So we have exact base randomization via Pi. I'm still working on the Pi patch, and we're going to hopefully get that in base here by tonight. I ran into some issues with being able to compile the bootloader, so that's kind of important. So two of my favorite features, if an application... We're going to have three ways that you can toggle ASLR for individual binaries. One isn't implemented yet, that is FS extended attributes. So you can set an extended attribute for the binary in the FS that says, hey, don't apply ASLR when you're executing this application. Another way is to... If your application is misbehaving, you can jail that application and have ASLR turned off just for that jail. So you have ASLR turned on for your host OS and all your other jails, but for just this jail, you can have ASLR turned off. And my favorite feature overall is that I've tied into the file system firewall known as UGIDFW, which is part of the MAC framework, that allows you to specify dynamic rules as kind of like an IPFW style rules for controlling ASLR on a per binary and even like per user and per group basis. So it's pretty cool. So what's the difference from Windows in less binary than what you do? From Windows, we... If you have the same problem, that's what I'm asking. If Adobe would be installed on QDC, we'd have a chain of SOs or whatever. Yeah, it's kind of in Windows case, you can have an individual DLL that doesn't have ASLR turned on. And in FreeBSD's case, it would be the binary itself, not the shared object. But the shared object is in health as well? It is, but it's already...shared objects are compiled such that they're already randomizable. That's the nature of a shared object. It can be loaded anywhere in memory. And so previously, without the ASLR patches, shared objects were getting loaded in a deterministic way. They were always getting loaded at the same address. Even though they could be relocated, they weren't. So that's part of this ASLR patch is to do that for shared objects. And for all objects that binary loads, would have an ASLR applied or not applied, which is up to the pain of the study? Or would it be you can load a binary with ASLR turned on and some of the shared objects may have it turned off? No. It's the reverse. Shared objects will always get randomized unless ASLR is turned off for the binary or in the jail. So if your binary is not compiled as a position independent executable, though, compiling as a position independent executable turns your executable into a shared object pretty much. So if your executable itself is not compiled as a pie, then the executable will be loaded at a deterministic address in a deterministic way. So we kind of have the opposite of the same type of Windows problem, but in the opposite way. So yeah. And I'll show you how that all works. So here are all the settings, all the CCTL tunables. The status tunable says there's three different values for that. In-interbased, one is you have to have your applications opt-in via the, right now, just via the UGDFW or setting it to two says opt-out, meaning that applications, all applications will have ASLR applied except for the ones that you say you want to opt-out of. And three means that it's enabled globally that we're going to force ASLR to be turned on everywhere for every application. And so really my favorite feature is the UGDFW integration because you can create firewall rules that apply per user, per group, per file, per file, or per object. You can define an object as not a file, but as different ways. You can take a look at the man page for the object stuff. It's really cool. It's very powerful. But there is some ABI and KBI breakage with this. So if you are a third-party developer and you've developed based off of the libUGDFW stuff, then there is a little bit of ABI breakage. You'll need to recompile your application. API, there is no API breakage, so all your function calls and stuff will remain the same, but I did have to change some underlying structures. So an example rule would be for me if I want to disable ASLR for this test application, then I could say add a rule for my user only. When I run this test application, that small a means disable ASLR. So that's pretty cool. And if a different user runs that application, they get ASLR. Yeah. So this is kind of low-level details, the higher-level version of the low-level details. In currentpacks.c, those are just generic helper functions. And currentpacksaslr.c is where the sysctls are implemented and the math of how we're applying the ASLR is done. And iminjac.elf is where we're doing the runtime linker randomizations, and it's where we've implemented PySupport. So there is a potential issue with compiling as a Py, in that since we're randomizing the load address of the executable, you might end up with a non-null address, or, well, our implementation guarantees that you won't have a null mapping. So that's kind of important. We made, we needed, we double-checked and made sure that that isn't an issue. And null mappings will never happen with our ASLR and Py implementation. So this bullets a little out of date, as of today. There's two knobs that need to be set. One is user-controlled and one is developer-controlled. The user-controlled knob is with Py. So you put with Py in your make.conf or source.conf, if you just want source.conf, if you want Py, only for base, make.conf, if you want it globally. But applications, some applications don't support being compiled as a Py. And some applications kind of are buggy when ran as a Py. So each application must, this is the part that's out of date. I'm turning this opt-in to opt-out. So by default, applications in base will compile as a Py, except for those that have the noPy equals yes flag. So I'm adding, what's that? Are you imp? Okay. There isn't really any other way. We'll talk. We'll talk. But I don't know if there's any other way to do it other than a no flag. So there is now. Cool. So I'll utilize that. Crap, I got to go and change all 30 different files. I'm changing them. No politics, isn't it crazy? Well, see, that's exactly it. They're helping me. They're like, hey, do it a different way, but they're helping me with it. Whereas with Linux, it'd be like, go screw yourself. But he could, but he doesn't. How does the New Yorker say, go to hell? But the next project is going to be dealing with the ports framework after this, and that's going to be a project in and of itself. So it's a good thing that I work with some ports people, just 20 feet away, well, a little bit more than that. But that's going to be my next major project, is adding Pi support to the ports framework. So how to use it? Compile your kernel with the PAX ASLR option. Right now, ASLR is not in base, so you have to apply a patch. So we're still in the call for testing phase. So apply the patch, add PAX ASLR to your kernel, recompile, install the kernel. By default, ASLR will be turned on when you compile with that kernel option. And if you use jails, child jails will inherit the parent jail settings. So that means if you have ASLR turned off for the parent, then when you boot up the new jail, ASLR will be turned off for the jail when it boots up. So, and if you want to take advantage of Pi support, then you have to compile your applications with the dash F Pi and dash Pi C flags, and ideally also add dash Pi to your LD flags as well. I'm going to skip this slide because our SAG fault protection, which is a recommended feature for ASLR but is not required, we're still working out the low level details of that. SAG fault protection is a very difficult thing to architect, and we're going between like two or three different designs and architectures for our implementation. So we're still a little bit undecided on how we want to implement that. Basically what SAG fault protection does is it frustrates the attacker that is trying to determine the inner workings of ASLR to see if there's any deterministic behavior. So like if there's a vulnerability that the attacker is triggering that causes a SAG fault, and like SSHD, SSHD will restart the process automatically if it crashes or if it exits. An attacker will basically do like a password brute force attack, but in this case a SAG fault brute force attack. SAG fault protection just adds a delay into restarting that application. Just one thing, Linux only has SAG fault, but these decals have lost error from where pointers get corrupted as well, so make sure that that's included as well. Okay, that's really good to know. I did not know that. Danilo Egea, who is a committer, is actually working on the SAG fault protection feature, and so I'll bring that up with him. So for future work, I need help with the ARM stuff. I don't know the ARM architecture very well. I attended yesterday's ARM intro presentation. That was really helpful, but I still don't know Jack about ARM. So if you own a Beagle, Bone Black or Raspberry Pi and you're willing to test this stuff out, get with me, and I'd love some help with that. Hopefully we're going to be committing the Pi support today after I remake all my changes to not do the no Pi thing. And we need testing. We need people to test this. I've been running the ASLR patches on my box for pretty much since its inception, and our ASLR implementation, at least for AMD64, is solid. I have not had a single issue. I now have Chrome, the Chromium project, compiled as a Pi, and it works great, except for HTML5 audio and video doesn't work anymore. I don't know why. So my end goal, though, is once ASLR is done and in base and Pi support is done and in base, and NX support is fixed on non-AMD64 and I think I36 architectures, then I'm going to work on more GR second-packs features. I'm probably going to work on WXORX next and then M Protect. So now is the demo. So you can see in this test application, basically all I'm doing is I've got a pointer that points to some data, and I'm just pointing out the address, printing out the address of that pointer. So you can see, CTO Security.packs.aslr. You can see I've got ASLR turned on. I am, wow, just had a brain fart. I'm randomizing 21 bits of M-Map calls and 21 bits of the exec base. That's Pi. The exec line is for Pi. So when I run this application, you'll see that that address gets randomized each time. So CTO Security.packs.aslr.status.0. So I've got ASLR turned off globally and that address isn't randomized anymore. So right now what I'm doing is I'm adding a UGIT FW, a firewall, or file system firewall rule to disable ASLR for that one application. Actually what I'm going to do is I'm going to disable ASLR just for that application. This mode says I can read the file and execute it. The Packs Flags option, which is optional, the lowercase a means ASLR is disabled for this application. The uppercase a means it's enabled. So if we're running an opt-in basis, using a capital A, we'll say I'm opting in this application to ASLR. So now you can see the behaviors the same, but Security.packs.aslr.status. We can see that ASLR is enabled, but it is disabled for that application. So I copied test to test to you, so it's a different file. We can see that ASLR is still working, but for other files. Can you run it just with 3D so we can see the firewall? The firewall rule? Yeah. It is? Oh, no, just run test. Oh, yes. It's a different user. Yep. So running it as a different user means ASLR is applied for that file. I chose 10 because it's a nice easy number to remember. So now that I removed the firewall rule, ASLR is enabled. So that's really it for the presentation. I wanted to thank a few people. Silverpinter is the one who initially started development on the ASLR feature. What happened was I had pointed out, I had posted on my little tech blog that I was going to start working on ASLR for free BSD. And then he somehow saw that post and then contacted me and said, hey, let's work together. So I added the per jail support, PI support, and the UJIT FW stuff. And he did quite a few other awesome things. Danilo Egea, he's working on the SEG VGARD feature. And Ryan Steinmetz is the ports committer and ports sec team member that I work with. He's awesome. I'm probably going to murder this name. Johannes Maksner, no clue how to say that last name. He convinced me to send a status report for the quarterly status report, which got some people interested in and added some more testers to CFTQ. And to SoldierX for donating hardware and support otherwise. So these slides are online. It's just a text file that you can open up with VIM, Emacs, whatever. So these are some references. And thank you very much for coming. Thank you.
 We've got quite a few projects underneath us and ASLR is one of the projects that we took on.  And while people are joining in, while people are still filing in, I thought I would have a little egotistical moment  and talk a little bit about me.  I'm a big fan of open source.  When I started learning how to program, when I was like 12 or so, I didn't even have a computer.  I wrote in C on like a piece of paper or anything. It really sucked.  And so did my code.  But I'm a big fan of open source.  When we got a computer and I finally got online, I would look at other people's source code and learn from others.  That was a big help.  I love freeBSD and ZFS.  Great technologies in freeBSD.  ZFS is amazing.  I'm such a fanboy of ZFS that I even have it running on my little netbook, which kind of sucks.  Makes it a little bit slow, but it works.  I'm passionate about security.  The first time I got online, I was like 14.  And I spent a whole month convincing my parents that we need a 56k dial-up modem.  And we got online using that free trial of AOL.  And then I found out about NetZero and Juno.  So NetZero and Juno, they provide free dial-up service, or they did at the time.  But they made it so that you had to install Adware on your system.  So it would be a program that displays just a little rectangular image with ads.  I'm like, dude, this takes up a lot of my precious dial-up bandwidth.  I can't deal with this.  And so my first experience with security was downloading a hex editor and looking at how the strings and stuff,  how the dial-up program authenticated and grepping through using strings to look at all the 800 dial-up numbers.  So we didn't have to call long distance either.  And so I found out what numbers it uses and how it authenticates with their servers.  And I ended up scripting my own little dial-up connection clients so that I wouldn't have to use their Adware.  So that was pretty fun.  I've submitted a few patches to FreeBSD.  By far, ASLR is the biggest.  I'm a maintainer of a few FreeBSD ports, mainly dealing with jails and Go and Drupal.  I'm the author of Libhijak.  Dude, I remember you.  That's not necessarily good.  I spoke last year about it.  It's a tool that makes a shared library that makes runtime process infection easy on Linux and FreeBSD.  It's a pretty cool tool.  You can inject shell code in as little as eight lines of C code.  It's pretty nifty.  One of my friends right now is porting it to ARM for Linux.  So eventually, hopefully, we'll use Libhijak for a lot of security things on Android devices.  A little bit of a disclaimer.  Of course, I have to put this to satisfy the legal department.  Any opinions, thoughts, ideas, tools, blah, blah, blah, they reflect me only.  And SoldierX, not any of my previous employers, my current employers, or future employers.  So I'm here on my own accord.  I am representing SoldierX here today because they've donated hardware to the project.  They've donated resources.  They're pretty cool peeps.  So what we're going to do is we're going to start off with a few definitions.  We're going to start off, you know, try to get on the same page with what ASLR is and the history behind it.  Then we're going to talk about FreeBSD security strengths and their weaknesses, some of the things that need to be improved upon.  And then we're going to talk about what we can learn from others because FreeBSD is pretty much the last enterprise operating system to implement ASLR.  And so we have the unique opportunity to learn from the strengths and mistakes of others.  Then I'm going to talk about how we've implemented ASLR in a very kind of high level detail because I've only got 45 minutes.  In ASLR, ASLR touches quite a few different places in the system.  In the source code, I don't have the time to go in depth.  But I'm at least going to show you the files that are modified and what we do.  Then I'm going to talk about how to use ASLR in FreeBSD and what needs to happen next.  Then I've got a live demo and I did sacrifice 3.5 goats to the demo gods.  And the goat BOF was born.  So for definitions, security, it's what Sony and Mt. Gox have in common.  They suck at it.  Really, security is just an onion that's made up of ever increasing layers.  And the more layers you have, the more time and resources it's going to take an attacker to successfully exploit your system.  So we have many different layers.  One of those layers are different exploit mitigation technologies, techniques.  An exploit mitigation technique is a method or technique to prevent the successful exploitation of security vulnerabilities.  Our computers have millions and millions and millions of lines of code in them.  All these programs, dozens of programs, hundreds of programs we run on our computer.  We don't know where the vulnerabilities lie.  But an attacker, a dedicated attacker is going to use whatever means possible to pop a shell on your box.  And so exploit mitigation technologies allow you to secure your system from the unknown.  At least help in giving you more time to be able to address security vulnerabilities.  ASLR is one such exploit mitigation technology.  It is address based layout randomization.  So what happens is, without ASLR, your application that you want to run like Firefox, for example, says to the operating system,  I expect to be loaded at this address. My data is here. I need it here.  If it's not here, I'm going to crash.  And so your program is loaded in a deterministic way.  So if there's a vulnerable function, if there's a piece of data that an attacker is interested in,  either a vulnerable function or a password stored in memory, a social security number, credit card number, whatever it is,  then the attacker knows exactly how to reach that point in memory and trigger that vulnerability.  What ASLR does is it randomizes where the program and its dependencies are loaded in memory.  So the attacker doesn't know, the attacker knows that there is a vulnerability, but he doesn't know where in memory it is.  So the program like Firefox, I was saying, for example, will tell the operating system,  hey, I can be loaded anywhere in memory. That's fine.  My data can be loaded anywhere in memory. I'll make do. You just tell me where I'm loaded and we'll make amends.  So ASLR helps protect against very low-level attacks, buffer overflows, return to libc,  and when you mix that with full format string vulnerabilities and integer overflows.  So really low-level things. ASLR doesn't help protect against PHP, LFI, and RFI,  and SQL injection attacks and cross-site scripting, all that fun stuff.  That's too high-level for ASLR.  So we're really just talking about really low-level vulnerabilities here.  You can think of exploits like Stuxnet and Flame and even Heartbleed,  even though ASLR wouldn't have helped in the Heartbleed case, but same kind of low-level type of thing.  To give a little bit of history, this is all on Wikipedia, so thanks Wikipedia University.  Just to get on the same page, though, in 2001, we now know that the PAX team is just a single person,  but at the time we didn't know if it was one person or multiple people.  So I still call them the PAX team just because that's how we've called them over the years.  They implemented as a third-party patch ASLR for Linux.  And in 2004, OpenBSD picked up that patch and it took open...  You didn't know about it.  Oh, you didn't?  It wasn't in any of them.  Oh, okay.  Sorry.  Well, then that was wrong.  Well, in 2004, OpenBSD started implementing ASLR.  I think it, I guess, maybe not based on PAX, but at least their current implementation is based on PAX, I believe.  No?  Really?  Okay.  All right.  It may have been based on the same research.  Okay.  But none of the code.  None of the code.  None of the code.  I don't think of any of the better papers.  Okay.  All right.  Well, I learned something new every day.  So it took OpenBSD four years to implement ASLR, but to their credit, they had a lot more work to do.  They had to change a whole lot of stuff in order to support ASLR because we're coming at this a little bit behind.  We don't have to change as much stuff.  There's not a lot, not as many prerequisites for implementing ASLR.  For us, it's already been done.  In 2005, Linux ripped PAX's ASLR and they dumbed it down, called it more secure, and did a lot of politics bull crap there.  I'll talk a bit about more about Linux and I know I learned from others' slide.  In 2007, Microsoft introduced ASLR into Windows Vista.  Their initial ASLR implementation was crap.  Very easy to bypass, extremely easy.  It was pretty much useless.  They made some design and architecture decisions that were more of a mistake that last till today because they had to add some fields to the PE header to say, we'll talk about that later.  They introduced ASLR in 2007.  It took Apple five years to finish up their ASLR work for OS 10, which they started in 2007.  In 2011, Sun or Oracle, I don't remember what year Oracle bought Sun, but they introduced ASLR into Solaris 11.  In 2014, Oliver Pinter and I submitted call for testing emails to the mailing list for our ASLR implementation on FreeBSD.  FreeBSD has a lot of security strengths.  FreeBSD's security mainly relies on policy-based security decisions.  The Mac framework, NFSV4 and Post-6 ACL, secure level, auditisty and jails.  You can think of jails and beehive as sort of a policy-based security because you're saying that I don't trust this application so I'm going to jail it.  FreeBSD has kind of a hybrid policy-based and exploit mitigation technology, sandboxing, known as Capsicum.  That's a pretty good implementation. Sandboxing is pretty cool.  I don't have that listed on the slide. I forgot to put it, but Capsicum seems to be pretty useful, pretty promising for the future.  Non-policy technology. These are exploit mitigation technologies, non-exec stack for AMD64 and P-Trace restrictions.  Fun little fact is the P-Trace restriction prevents lib hijack from working.  FreeBSD does have a few weaknesses. There were the non-exec stack.  That means that you can put your shell code on the stack. When you're exploiting an application, your end goal is to run arbitrary code known as shell code.  But you can store it on the stack. You're just not going to get it to run on the stack.  FreeBSD has that, but it's not working on all platforms.  I have a Raspberry Pi and supposedly it supports a non-exec stack, but it doesn't.  Once we're finished with the ASLR patch itself, I'm going to go back and take a look and see why non-exec stack isn't being obeyed on ARM.  One of the things that goes hand in hand with ASLR is called position independent executable support.  I'm going to call that Pi because that's a lot easier to say than position independent executable.  ASLR, really, to be effective, needs Pi support. That's the part that tells the operating system,  that the program can be loaded anywhere in memory. For ASLR to be effective, Pi support needs to happen in base.  I'm actually working on that right now and hoping to get a patch up to Brian Drury tonight to be merged into your head.  That will be coming here soon. Of course, there's no ASLR in FreeBSD. That's why we're talking about it.  GRSec is a third-party patch to the Linux kernel that hardens the kernel and the user land.  My end goal is to port all the features that make sense for FreeBSD to FreeBSD.  To learn from others, Linux is really political. It's a territorial pissing contest when it comes to this kind of stuff.  What they did was they saw PAX's work, but they didn't want an implementation from an anonymous author.  We didn't know. The Linux guys didn't know who wrote PAX's ASLR implementation. They wanted something of their own.  Instead of trying to figure out who it was and contact them, there's an actual email address for them.  They could have just emailed the guy. They ripped PAX's code and dumbed it down and called it more secure.  The one thing that drives me to FreeBSD more than anything, I love FreeBSD's technologies,  the one thing that drives me to FreeBSD over everything is the lack of politics.  When it comes to this kind of stuff, I sat down with Desk the other day.  I was kind of scared because this is the first time that I ever had a major patch review.  I was kind of scared. It was more about the technology. He had some ideas and suggestions.  It's more like, you've got a patch, that's cool. We need to get this in.  But first, let's fix a few issues. It's more about the technology with FreeBSD than the territorial pissing contest.  That's been my experience. Other people's experience may vary, but that's been my experience when submitting patches  and helping out the FreeBSD project. It's not nearly as mind-numbing as it is with Linux.  Technologically speaking, Linux is ASLR. I'm not going to talk about packs because Linux's actual ASLR implementation is pretty weak and pretty dumb.  It's either turn ASLR on globally or turn it off globally.  If you want this exploit mitigation technology on your system, but you have one application that is closed source, kind of like Flash or the NVIDIA binaries.  What do you want to have ASLR for?  If an application that is misbehaving under ASLR, like it's crashing or there's other bugs, then you have to have ASLR turned off for the whole system.  That's stupid. The two things that I took away from this is that we need to randomize enough bits because that's the problem with Linux's AS.  That's one of the problems with Linux's ASLR is that they're not randomizing enough bits.  There's no way to control how many bits you want to randomize.  There's no way to toggle it on a per application basis.  That's kind of a half-lie, but not really.  This command up there, that set arch right there, you have to use that command every single time you run this application that you want ASLR disabled for.  It's kind of stupid.  If you have an application that gets started via init scripts, you have to go and modify init scripts to disable ASLR.  Every time you update the package for that, you have to back out your modifications, let the package update, and then reinsert your modifications.  It's stupid.  One of the things that I learned from Linux is we want to be more flexible and more dynamic than that.  Windows, now with Windows 7, Windows 8, they have a pretty decent technical implementation.  The biggest issue there is individual DLLs and EXCs can have ASLR turned on or off.  In EXC, both EXCs and DLLs are just PE files.  There is a bit inside of the PE file that says, for this object, ASLR is turned on or off.  You can have an EXC that depends on, let's say, five DLLs, for example.  We'll say the EXC has ASLR turned on and four out of the five DLLs have ASLR turned off.  That means one DLL has ASLR turned off.  The windows will apply ASLR to the EXC and to the four DLLs, and ASLR won't get applied to the one DLL.  We'll be in this hybrid state where ASLR was applied but not.  That is a big issue because, for example, just recently, I can't name the vendor,  but there was one vendor who, if you use Windows, you probably use their software every day or nearly every day,  especially if you're looking at documentation.  They had just released a new version of their software and it depended on quite a few different DLLs.  It was just that exact same scenario.  They had compiled their applications with ASLR support and all the DLLs except for one.  There was a vulnerability in one of the DLLs that had ASLR turned on,  but the call stack was such that the control flow could be controlled via the DLL that had ASLR turned off.  Because they could use that DLL that had ASLR turned off, because that was loaded in a deterministic way,  attackers were able to successfully exploit the application using nothing more than just your standard exploitation techniques.  That can be a major issue.  We still have that kind of issue with the ELF file format on FreeBSD,  but that's because the ELF file format was designed years and years and years and years way before ASLR was even thought of.  That's why pie support is really important, because otherwise you're not randomizing all of the address space.  If you don't have pie support for that application, you're still randomizing where the dependencies, the shared objects, get loaded,  but not the binary itself.  So you still kind of have that DLL issue just in reverse.  So ASLR is available for FreeBSD, is available on all architectures FreeBSD supports with some...  We don't have hardware for all architectures, of course, so your mileage may vary.  We actively test on AMD64, i386 ARM, and kind of Spark64, vanilla FreeBSD, just FreeBSD11 current without the ASLR patches at all,  has issues on Spark64, so I haven't been able to test the ASLR stuff too much on Spark64.  So we have exact base randomization via Pi.  I'm still working on the Pi patch, and we're going to hopefully get that in base here by tonight.  I ran into some issues with being able to compile the bootloader, so that's kind of important.  So two of my favorite features, if an application... We're going to have three ways that you can toggle ASLR for individual binaries.  One isn't implemented yet, that is FS extended attributes.  So you can set an extended attribute for the binary in the FS that says, hey, don't apply ASLR when you're executing this application.  Another way is to... If your application is misbehaving, you can jail that application and have ASLR turned off just for that jail.  So you have ASLR turned on for your host OS and all your other jails, but for just this jail, you can have ASLR turned off.  And my favorite feature overall is that I've tied into the file system firewall known as UGIDFW, which is part of the MAC framework,  that allows you to specify dynamic rules as kind of like an IPFW style rules for controlling ASLR on a per binary and even like per user and per group basis.  So it's pretty cool.  So what's the difference from Windows in less binary than what you do?  From Windows, we...  If you have the same problem, that's what I'm asking.  If Adobe would be installed on QDC, we'd have a chain of SOs or whatever.  Yeah, it's kind of in Windows case, you can have an individual DLL that doesn't have ASLR turned on.  And in FreeBSD's case, it would be the binary itself, not the shared object.  But the shared object is in health as well?  It is, but it's already...shared objects are compiled such that they're already randomizable.  That's the nature of a shared object. It can be loaded anywhere in memory.  And so previously, without the ASLR patches, shared objects were getting loaded in a deterministic way.  They were always getting loaded at the same address.  Even though they could be relocated, they weren't.  So that's part of this ASLR patch is to do that for shared objects.  And for all objects that binary loads, would have an ASLR applied or not applied, which is up to the pain of the study?  Or would it be you can load a binary with ASLR turned on and some of the shared objects may have it turned off?  No. It's the reverse.  Shared objects will always get randomized unless ASLR is turned off for the binary or in the jail.  So if your binary is not compiled as a position independent executable, though,  compiling as a position independent executable turns your executable into a shared object pretty much.  So if your executable itself is not compiled as a pie, then the executable will be loaded at a deterministic address in a deterministic way.  So we kind of have the opposite of the same type of Windows problem, but in the opposite way.  So yeah. And I'll show you how that all works.  So here are all the settings, all the CCTL tunables.  The status tunable says there's three different values for that.  In-interbased, one is you have to have your applications opt-in via the, right now,  just via the UGDFW or setting it to two says opt-out,  meaning that applications, all applications will have ASLR applied except for the ones that you say you want to opt-out of.  And three means that it's enabled globally that we're going to force ASLR to be turned on everywhere for every application.  And so really my favorite feature is the UGDFW integration because you can create firewall rules that apply per user, per group, per file, per file, or per object.  You can define an object as not a file, but as different ways.  You can take a look at the man page for the object stuff. It's really cool. It's very powerful.  But there is some ABI and KBI breakage with this.  So if you are a third-party developer and you've developed based off of the libUGDFW stuff,  then there is a little bit of ABI breakage. You'll need to recompile your application.  API, there is no API breakage, so all your function calls and stuff will remain the same,  but I did have to change some underlying structures.  So an example rule would be for me if I want to disable ASLR for this test application,  then I could say add a rule for my user only. When I run this test application, that small a means disable ASLR.  So that's pretty cool.  And if a different user runs that application, they get ASLR.  Yeah. So this is kind of low-level details, the higher-level version of the low-level details.  In currentpacks.c, those are just generic helper functions.  And currentpacksaslr.c is where the sysctls are implemented and the math of how we're applying the ASLR is done.  And iminjac.elf is where we're doing the runtime linker randomizations, and it's where we've implemented PySupport.  So there is a potential issue with compiling as a Py,  in that since we're randomizing the load address of the executable,  you might end up with a non-null address, or, well, our implementation guarantees that you won't have a null mapping.  So that's kind of important. We made, we needed, we double-checked and made sure that that isn't an issue.  And null mappings will never happen with our ASLR and Py implementation.  So this bullets a little out of date, as of today.  There's two knobs that need to be set. One is user-controlled and one is developer-controlled.  The user-controlled knob is with Py. So you put with Py in your make.conf or source.conf,  if you just want source.conf, if you want Py, only for base, make.conf, if you want it globally.  But applications, some applications don't support being compiled as a Py.  And some applications kind of are buggy when ran as a Py.  So each application must, this is the part that's out of date.  I'm turning this opt-in to opt-out. So by default, applications in base will compile as a Py,  except for those that have the noPy equals yes flag.  So I'm adding, what's that? Are you imp?  Okay.  There isn't really any other way. We'll talk. We'll talk.  But I don't know if there's any other way to do it other than a no flag.  So there is now. Cool.  So I'll utilize that. Crap, I got to go and change all 30 different files.  I'm changing them.  No politics, isn't it crazy?  Well, see, that's exactly it. They're helping me. They're like, hey, do it a different way,  but they're helping me with it.  Whereas with Linux, it'd be like, go screw yourself.  But he could, but he doesn't.  How does the New Yorker say, go to hell?  But the next project is going to be dealing with the ports framework after this,  and that's going to be a project in and of itself.  So it's a good thing that I work with some ports people, just 20 feet away,  well, a little bit more than that.  But that's going to be my next major project, is adding Pi support to the ports framework.  So how to use it? Compile your kernel with the PAX ASLR option.  Right now, ASLR is not in base, so you have to apply a patch.  So we're still in the call for testing phase.  So apply the patch, add PAX ASLR to your kernel, recompile, install the kernel.  By default, ASLR will be turned on when you compile with that kernel option.  And if you use jails, child jails will inherit the parent jail settings.  So that means if you have ASLR turned off for the parent,  then when you boot up the new jail, ASLR will be turned off for the jail when it boots up.  So, and if you want to take advantage of Pi support,  then you have to compile your applications with the dash F Pi and dash Pi C flags,  and ideally also add dash Pi to your LD flags as well.  I'm going to skip this slide because our SAG fault protection,  which is a recommended feature for ASLR but is not required,  we're still working out the low level details of that.  SAG fault protection is a very difficult thing to architect,  and we're going between like two or three different designs and architectures for our implementation.  So we're still a little bit undecided on how we want to implement that.  Basically what SAG fault protection does is it frustrates the attacker that is trying to determine  the inner workings of ASLR to see if there's any deterministic behavior.  So like if there's a vulnerability that the attacker is triggering that causes a SAG fault,  and like SSHD, SSHD will restart the process automatically if it crashes or if it exits.  An attacker will basically do like a password brute force attack, but in this case a SAG fault brute force attack.  SAG fault protection just adds a delay into restarting that application.  Just one thing, Linux only has SAG fault, but these decals have lost error from where pointers get corrupted as well,  so make sure that that's included as well.  Okay, that's really good to know. I did not know that.  Danilo Egea, who is a committer, is actually working on the SAG fault protection feature,  and so I'll bring that up with him.  So for future work, I need help with the ARM stuff.  I don't know the ARM architecture very well.  I attended yesterday's ARM intro presentation.  That was really helpful, but I still don't know Jack about ARM.  So if you own a Beagle, Bone Black or Raspberry Pi and you're willing to test this stuff out,  get with me, and I'd love some help with that.  Hopefully we're going to be committing the Pi support today after I remake all my changes to not do the no Pi thing.  And we need testing. We need people to test this.  I've been running the ASLR patches on my box for pretty much since its inception,  and our ASLR implementation, at least for AMD64, is solid.  I have not had a single issue.  I now have Chrome, the Chromium project, compiled as a Pi, and it works great,  except for HTML5 audio and video doesn't work anymore.  I don't know why.  So my end goal, though, is once ASLR is done and in base and Pi support is done and in base,  and NX support is fixed on non-AMD64 and I think I36 architectures,  then I'm going to work on more GR second-packs features.  I'm probably going to work on WXORX next and then M Protect.  So now is the demo.  So you can see in this test application, basically all I'm doing is I've got a pointer that points to some data,  and I'm just pointing out the address, printing out the address of that pointer.  So you can see, CTO Security.packs.aslr.  You can see I've got ASLR turned on.  I am, wow, just had a brain fart.  I'm randomizing 21 bits of M-Map calls and 21 bits of the exec base.  That's Pi. The exec line is for Pi.  So when I run this application, you'll see that that address gets randomized each time.  So CTO Security.packs.aslr.status.0.  So I've got ASLR turned off globally and that address isn't randomized anymore.  So right now what I'm doing is I'm adding a UGIT FW, a firewall, or file system firewall rule to disable ASLR for that one application.  Actually what I'm going to do is I'm going to disable ASLR just for that application.  This mode says I can read the file and execute it.  The Packs Flags option, which is optional, the lowercase a means ASLR is disabled for this application.  The uppercase a means it's enabled.  So if we're running an opt-in basis, using a capital A, we'll say I'm opting in this application to ASLR.  So now you can see the behaviors the same, but Security.packs.aslr.status.  We can see that ASLR is enabled, but it is disabled for that application.  So I copied test to test to you, so it's a different file.  We can see that ASLR is still working, but for other files.  Can you run it just with 3D so we can see the firewall?  The firewall rule?  Yeah.  It is?  Oh, no, just run test.  Oh, yes.  It's a different user.  Yep.  So running it as a different user means ASLR is applied for that file.  I chose 10 because it's a nice easy number to remember.  So now that I removed the firewall rule, ASLR is enabled.  So that's really it for the presentation.  I wanted to thank a few people.  Silverpinter is the one who initially started development on the ASLR feature.  What happened was I had pointed out, I had posted on my little tech blog that I was going to start working on ASLR for free BSD.  And then he somehow saw that post and then contacted me and said, hey, let's work together.  So I added the per jail support, PI support, and the UJIT FW stuff.  And he did quite a few other awesome things.  Danilo Egea, he's working on the SEG VGARD feature.  And Ryan Steinmetz is the ports committer and ports sec team member that I work with.  He's awesome.  I'm probably going to murder this name.  Johannes Maksner, no clue how to say that last name.  He convinced me to send a status report for the quarterly status report,  which got some people interested in and added some more testers to CFTQ.  And to SoldierX for donating hardware and support otherwise.  So these slides are online.  It's just a text file that you can open up with VIM, Emacs, whatever.  So these are some references.  And thank you very much for coming.  Thank you.
Introducing_ASLR_in_FreeBSD__720p__0_47.png Introducing_ASLR_in_FreeBSD__720p__48_203.png Introducing_ASLR_in_FreeBSD__720p__204_6275.png Introducing_ASLR_in_FreeBSD__720p__6276_8243.png Introducing_ASLR_in_FreeBSD__720p__8244_13979.png Introducing_ASLR_in_FreeBSD__720p__13980_19043.png Introducing_ASLR_in_FreeBSD__720p__19044_20927.png Introducing_ASLR_in_FreeBSD__720p__20928_24119.png Introducing_ASLR_in_FreeBSD__720p__24120_35627.png Introducing_ASLR_in_FreeBSD__720p__35628_39215.png Introducing_ASLR_in_FreeBSD__720p__39216_39347.png Introducing_ASLR_in_FreeBSD__720p__39348_42863.png Introducing_ASLR_in_FreeBSD__720p__42864_44231.png Introducing_ASLR_in_FreeBSD__720p__44232_46415.png Introducing_ASLR_in_FreeBSD__720p__46416_52811.png Introducing_ASLR_in_FreeBSD__720p__52812_54659.png Introducing_ASLR_in_FreeBSD__720p__54660_57239.png Introducing_ASLR_in_FreeBSD__720p__57240_59963.png Introducing_ASLR_in_FreeBSD__720p__59964_60011.png Introducing_ASLR_in_FreeBSD__720p__60012_60071.png Introducing_ASLR_in_FreeBSD__720p__60072_60119.png Introducing_ASLR_in_FreeBSD__720p__60120_60551.png Introducing_ASLR_in_FreeBSD__720p__60552_61247.png Introducing_ASLR_in_FreeBSD__720p__61248_61295.png Introducing_ASLR_in_FreeBSD__720p__61296_61343.png Introducing_ASLR_in_FreeBSD__720p__61344_61547.png Introducing_ASLR_in_FreeBSD__720p__61548_61595.png Introducing_ASLR_in_FreeBSD__720p__61596_61643.png Introducing_ASLR_in_FreeBSD__720p__61644_61691.png Introducing_ASLR_in_FreeBSD__720p__61692_61739.png Introducing_ASLR_in_FreeBSD__720p__61740_61799.png Introducing_ASLR_in_FreeBSD__720p__61800_61847.png Introducing_ASLR_in_FreeBSD__720p__61848_61967.png Introducing_ASLR_in_FreeBSD__720p__61968_62411.png Introducing_ASLR_in_FreeBSD__720p__62412_62459.png Introducing_ASLR_in_FreeBSD__720p__62460_62603.png Introducing_ASLR_in_FreeBSD__720p__62604_62663.png Introducing_ASLR_in_FreeBSD__720p__62664_62759.png Introducing_ASLR_in_FreeBSD__720p__62760_62807.png Introducing_ASLR_in_FreeBSD__720p__62808_62927.png Introducing_ASLR_in_FreeBSD__720p__62928_62975.png Introducing_ASLR_in_FreeBSD__720p__62976_63035.png Introducing_ASLR_in_FreeBSD__720p__63036_63095.png Introducing_ASLR_in_FreeBSD__720p__63096_63923.png Introducing_ASLR_in_FreeBSD__720p__63924_63971.png Introducing_ASLR_in_FreeBSD__720p__63972_64019.png Introducing_ASLR_in_FreeBSD__720p__64020_64103.png Introducing_ASLR_in_FreeBSD__720p__64104_64151.png Introducing_ASLR_in_FreeBSD__720p__64152_64331.png Introducing_ASLR_in_FreeBSD__720p__64332_64475.png Introducing_ASLR_in_FreeBSD__720p__64476_64523.png Introducing_ASLR_in_FreeBSD__720p__64524_64871.png Introducing_ASLR_in_FreeBSD__720p__64872_64919.png Introducing_ASLR_in_FreeBSD__720p__64920_65159.png Introducing_ASLR_in_FreeBSD__720p__65160_65219.png Introducing_ASLR_in_FreeBSD__720p__65220_65267.png Introducing_ASLR_in_FreeBSD__720p__65268_65315.png Introducing_ASLR_in_FreeBSD__720p__65316_65459.png Introducing_ASLR_in_FreeBSD__720p__65460_65507.png Introducing_ASLR_in_FreeBSD__720p__65508_65591.png Introducing_ASLR_in_FreeBSD__720p__65592_67475.png Introducing_ASLR_in_FreeBSD__720p__67476_67799.png Introducing_ASLR_in_FreeBSD__720p__67800_67965.png