 So thank you for coming out. My name is Sean Webb. I go by the hand of Lattera online. And as people are coming in, I thought I would introduce Groff. As you all know, this is my lovely goat. He was born at BSD Can. And he was born because I had tweeted, and it caused a tweet storm about how I was preparing for my ASLR presentation for BSD Can. And I had yet to sacrifice the traditional three and a half goats. So Alan Jude and a few others picked it up. And he suggested that Alan Jude pick up a goat for BSD Can so that I didn't have to bring one through US Customs. So Groff was born, and he is my little baby. I love him. So today's presentation is about address space layout randomization, or ASLR for short. While people are filling in, I'm going to have a moment of arrogance and egotism. I'm going to talk about myself. So my name is Sean Webb. I'm a big fan of open source. And I was introduced to free BSD when I was a teenager. And I had joined an internet and online hacking community. And they introduced me to free BSD and how it's much more hacker-like than even slackware. And I just fell in love from day one. I'm passionate about security. I have been working in the security industry for the past few years. And my first introduction to security when I was about 14, 15 years old and introduced to the internet. A lot of you will recognize the names NetZero and Juno. They offered free dial-up service if you agreed to install a piece of adware on your computer that would dial in to their network for you. And then once you're connected, it would display some ads. Well, I figured that dial-up is precious band with, and I don't want these big banners on my screen. It takes up a lot of bandwidth. So I ran a hex editor and strings. And I found out what numbers they were using to dial in and how they did the authentication mechanisms. And I was able to reverse engineer that and created my own dial-up script to not have to deal with the adware. So from that day on, I loved security. Taking a look at things and manipulating things that the original developers or designers never thought of. I submitted a few insignificant patches to FreeBSD. I worked on setFACL, getFACL. I'm a maintainer of a few ports, which are pretty much defunct now because I submitted them because they were my projects. And I didn't want to maintain my own custom port sentry. Maybe some people use them, but mainly I think it's just me. And I authored a tool called Libhijak, originally for Linux. And I ported it over to FreeBSD and spoke about that at last year's BSD Can. It's a tool that makes runtime process infection and injection of shell code and arbitrary shared objects extremely easy on Linux and FreeBSD. I'm the co-founder of the Hardin BSD project. I'll be talking more about the OpenBSD project at the end of the presentation. And to satisfy my lawyers or my employer's lawyers, rather, anything that I say here, any opinions, ideas, thoughts, implementations, projects, that kind of stuff, they represent me and me only. Well, actually, I'm representing Hardin BSD and SoldierX. SoldierX is an online security community, of which I'm a member. And nothing but nothing reflects any of my previous employers, current employers, or future employers. So what we're going to do today is we're going to talk. We're going to start out with some definitions. So we're on the same plane level. And we're going to go through the history of ASLR. Thank you to Wikipedia University. And then we're going to talk about what FreeBSD has done well in security. And we're going to talk about what needs to what weaknesses they have and what needs to be done further. Since we're a little bit late to the game with ASLR, we have the unique opportunity to learn from others. FreeBSD is really the only enterprise operating system that does not have ASLR. So we can take this opportunity to learn from others, their implementations, and some of the social and political aspects of those implementations as well. We're going to talk next about how we've implemented ASLR and how to use it on FreeBSD. Then we're going to talk about what's next to do, what's left, and then if time permits, because I've only got 45 minutes, a live demo. So security, what is security? It's what Mt. Gox and Sony have in common. They suck at it. Really, security is an onion. It's an ever-increasing layers of an onion that make everyone tear up. The more layers of security you have, the more time it takes an attacker to successfully exploit your system. Layers of security are called exploit mitigations. An exploit mitigation is a method or technique used to prevent the successful exploitation of security vulnerabilities. One such exploitation mitigation technique is called ASLR, address space layout randomization. ASLR is what it does is it randomizes the memory layout of a program. If you don't have ASLR on your system or don't have it enabled, your program is going to tell the operating system where it needs to be loaded in memory. If it's not loaded at that place in memory, it's going to crash. It's not going to work right. Well, what ASLR does is it allows the program to tell the operating system, hey, I can be loaded anywhere. But so load me anywhere, load me in a random spot, and I'll make do. I'll figure out where I am. I'll figure out where my variables are, where my functions are, and I'll make do. What ASLR helps protect against is very low-level things, buffer overflow attacks, integer overflow attacks. You're very basic and low-level vulnerabilities. But it does not help protect against higher-level vulnerabilities, such as misconfiguring pseudo, or PHP, LFI, or RFI vulnerabilities. Really, we're talking at a very low-level vulnerability here. A lot of people get mistaken that ASLR is the end-all, be-all of security. That once you have ASLR, that your system is completely secure, you don't need anything else. Well, that's not the case. There are techniques to break ASLR. So ASLR is not the end-all, be-all of security. But it is a good first step. It is one of the first layers that you need to apply in creating your onion of security. So a little bit of history. In 2001, the PAX team created a third-party patch to the Linux kernel. And this kernel implemented, among other things, ASLR. To this day, the PAX patch is still distributed as a third-party patch. So that was 13 years ago. A lot has changed since then. In 2004, OpenBSD started their work on implementing ASLR. They get everything except for Pi support, position-independent executable support. We'll talk more in depth about what a Pi is later on. In 2005, Linux did something incredibly stupid. And they keep doing this even in nine years later, almost 10, they keep doing similar things. What they did is they saw PAX's patch, and they're like, oh, that's a neat idea. Well, we're going to rip off your work. We're going to dumb it down, make it less secure, and market it as more secure. There was a lot of politics and a lot of drama regarding that patch. And I'll talk about that later. In 2007, Microsoft introduced ASLR for Windows Vista. Their implementation sucked for Windows Vista. They had some technical issues and some other big gaping issues that have survived to this day. So we'll talk more in depth about that later. In 2007, Apple started working on ASLR for OS10 and finished it in 2012. In 2008, OpenBSD completed their implementation for with Pi support. So that was the technical base implementation, the technical implementation that was required to finish it up in 2004. Actually, yeah, it was this year, I believe, with OpenBSD 5.5. So it took them 10 years to go from no ASLR to having ASLR fully enabled for all applications in base. And that's understandable. They had a lot of work to do. And in fact, you can see in 2014 Oliver Pinter, which I'm mispronouncing his name. He's from Hungary. And we Americans love to mispronounce names. He and I submitted our patch to FreeBSD. We've been working on it for over a year now. And so it's gonna take us a lot longer to have full ASLR on FreeBSD. I'm gonna guess another few years of work. So what FreeBSD has done well in the security industry is that they've done a lot of policy-based, policy-driven security. They have the Mac framework in Capsicum. The Mac framework is really awesome, really extendable. And Capsicum is a sandboxing framework that you have to integrate with in your applications. A developer needs to integrate with in his or her applications. They have NFSV4 and POSIX ACLs. So file system ACLs that drive security policy. They have secure level, which helps with the kernel so that you can't change, you can only do certain things if the secure level is set. You're forbidden from doing certain things. And AuditDistee, which shares, which sends all your audit logs off to another server so that if an attacker compromises your system, your audit logs are off on a different server that hopefully the attacker can't get to. You can think of containerization technologies and virtualization technologies as a form of policy-based security. If you don't trust your application, then chances are you're gonna wanna run it in a container or in a virtual environment. FreeBSD does have two non-policy-based security technologies, one of which is an exploit mitigation technology and that is the non-exec stack. Prior to, way back in the day, back when Aleph1 wrote his famous paper, Smashing the Stack for Fun and Profit, attackers would store their shell code on the stack and get it to run on the stack. Well, it's really popular nowadays for servers to have the stack as non-executable. So that is an exploit mitigation technique that no longer an attacker can store and run their shell code on the stack. Petrace restrictions, Petrace is awesome. I love it, that's what lib hijack uses. Pretty much makes you God mode in regards to exploiting or manipulating other processes. So what FreeBSD needs to improve on is that it needs to enable the non-exec stack on all architectures. The non-exec stack is only enabled by default on AMD64 and i386. It is not enabled and not even functional on ARM. So we need to get it enabled on more architectures and working on more architectures. We need position independent support, independent executable support in base. We had a patch, I had actually committed, well I didn't commit, I had upstreamed a patch to FreeBSD that enabled position independent executable support. There were issues with that patch and later it was reverted. So we need to revisit that and reimplement it. Of course there's no ASLR and FreeBSD, that's why this presentation exists, why you're here. There's another third-party patch to the Linux kernel that hardens both the Linux kernel and the user land called GR Security or GRsec for short. And my end goal is to port all features of GRsec to FreeBSD, the features that make sense for FreeBSD at least. So we have the opportunity to learn from others and we're gonna learn from Linux today. Linux developers love politics. I think they love it more than actually developing. What they did is they took PAX's patch, which is awesome, it's 13 years old and it's undergone a few changes over the past 13 years but by and large the underlying technique that he is using has withstood the test of time. Well the Linux developers took his patch, completely ripped it out and dumbed it down, imported their dumbed down and less secure version into the Linux kernel and then marketed it as more secure. I remember distinctly all the drama that happened with that. I was about to leave the security industry for the security scene for about two years and that had just barely gone on right before I left. And I remember that as if it were day and night, as if it were yesterday. Linux's ASLR has weaknesses, they're not randomizing enough bits and they're not randomizing them in the right way. And there's only one way you can, if you have a misbehaving application, if you have a close source application, we'll take Flash for an example, Flash does work but I'm gonna pick on it because I hate it. If Flash were to misbehave under ASLR, you would have to turn ASLR off for your whole system because you wanted to run Flash. That's not okay. That means for one application, you have to remove all security in your system, well not all but a good important piece of security in your system. And non-root users can disable ASLR for their applications. All they have to do is call fork and set a special personality, say in this newly forked process, I don't wanna randomize my environment. And then after, so it's fork, set the personality and then exec VE. So that's really stupid. Non-root users should never be able to disable ASLR. Windows, so Microsoft today with Windows 7 and especially Windows 8.1 has a really good implementation of ASLR. They're randomizing enough bits and they are randomizing them in the right way. But the problem is that individual DLLs that an executable might import can have ASLR turned off. So this was the case with a major software vendor whose name I will not mention, but they are used pretty much every day by a lot of people to look at documentation and to modify graphics files. They had shipped within this last year, one of their, one of their applications to generate documentation. And this application had ASLR turned on for the executable itself and for all of the DLLs it imported except for one DLL. And because of that one DLL, so what happens is Windows will load that executable with ASLR turned on in all of the DLLs with ASLR turned on except for that one DLL. So ASLR, that one DLL will be loaded in a deterministic way. That means that the attacker is now able to generate exploit payloads based off of that one DLL because it's loaded in a deterministic way. Every single time that that program is loaded up it's gonna be loaded at the same exact address. It's gonna be loaded in the same exact way every single time even across reboots. So that software vendor had done that. They released their application. They had a vulnerability in a DLL that was randomized that had ASLR turned on, but because of the one DLL that had ASLR turned off they were attackers were able to successfully exploit their application relatively easily. They didn't need to do any anti mitigation techniques. They just keyed off of that one DLL and they were able to pop a shell. Fortunately, Microsoft has this tool called Emmet and version 5.0 was released just within the past few months. Emmet is a tool that makes it so that you can force ASLR on and other exploit mitigation technology features on all the time for even for applications and DLLs that say I don't support ASLR. You can still force ASLR to be turned on for those applications and DLLs. So that's a really good, really great product there and it's free and if you run Windows I highly recommend as does everyone in the security industry I highly recommend you run Emmet and you run it in enforcing mode. But what we learned is that ASLR is not the end all be all of security. It's a good first step in exploit mitigation technologies. You can bypass ASLR using techniques called, using a technique called blind Rop. It's a technique that was published earlier this year at the Black Hat USA Conference and so it's a relatively new technique and it's kind of a little bit error prone. You have to try it a few times. Your victim application, your target application might crash while you're trying to generate dynamically Rop payloads. But it's a technique, nevertheless to get rid of, to bypass ASLR. So really what we need, the thing that we can take away from Windows is that we need a combination of exploit mitigation technologies. We're not gonna stop once ASLR is finished. Oliver and I are not gonna stop there. We're gonna continue working on adding exploit mitigation technologies to FreeBSD. And Microsoft has proven that that is absolutely required. So to introduce ASLR and FreeBSD, we support all architectures that FreeBSD supports. We're kind of limited right now because we're doing this out of our own pocket and we have, of course, AMD64 boxes and i386 boxes I have a BeagleBone Black and a Raspberry Pi. The BeagleBone Black was donated to me by SoldierX as well as a Spark64 box. ASLR and ARM is broken and I'm looking for help from people who know ARM well. If you wanna talk to me about the ARM breakage, see me after this presentation, well, see me once the conference is over because I wanna see Edmast's talk next about LDB. That looks really interesting. But ARM is broken pretty much and it's due to the stack and signal delivery. We can talk about that more later. Spark64, I couldn't get a FreeBSD head box, a FreeBSD11 current box, just vanilla running on Spark64. I have an old Spark box donated to me by the same people, the SoldierX community, but it's old and I couldn't get FreeBSD, the vanilla FreeBSD running on it. So we support exec base randomization for position independent executables and we support basic address layout, randomization for executables that aren't compiled as a Pi and we support per-jail ASLR settings. So what a Pi is, a position independent executable is it's an application that is compiled in such a way that it tells the operating system that it can be loaded anywhere in memory. Traditionally, your application will tell the operating system, like I said before, that it expects to be loaded at a certain place and that is due to how the ELF file format works. There's nothing we can do to change the ELF specification. That was created a long time ago by Sun over 20 years ago, I believe. And so in order to make full utilization of ASLR, in order to make full utilization of ASLR, you have to compile your application as a Pi as a position independent executable. We have the reverse problem that Microsoft has. Microsoft has a problem where individual DXC or DLLs might have ASLR turned off. We have the problem of an application itself might have ASLR turned off, but it's shared objects that it depends on or it's DLLs, so to speak, that it depends on will have ASLR turned on. And we can't, there's no way that we can turn ASLR off for individual shared objects. That's because of how the ELF spec works, how the ELF file format works. And that works out in our favor. So when you compile, what you have to do is you have to compile your kernel with a custom option, the PAX ASLR option. And when you do that, you'll have these knobs, these tunables that you can tune at boot time via bootloader.conf. And this is actually defaulted to two now rather than one in our implementation. When you look at the help, when you look at the help for those tunables, you'll see why it's zero, one, two, and three. There's different things that you can set. So the status sets, whether it's enabled, whether you want ASLR enabled, the bug is self-explanatory. The M-map line, that's how many bits of address space are we gonna randomize when M-map is called? The stack length is the same thing except for the stack. How many bits of the stack are we gonna randomize? And the exec base, the exec line is how many bits are we gonna randomize of the exec base of the position independent executable, where that position independent executable, the base of where it's loaded. So what happens when an application, when you have an application that doesn't support ASLR, it crashes or it misbehaves, it exhibits bugs, well what you can do is you can jail it. You can set, you can put that application inside of a jail and have ASLR turned off just for that jail. So you have ASLR turned on for everything else but except for that application or applications in that jail that don't support ASLR. And that's how we learned from Linux that we don't want one knob to rule them all. We want to be able to be flexible and support having security mitigation techniques, exploit mitigation techniques be enforceable on a per jail basis. So what we do is there's a few different ways you can implement ASLR. You can either sacrifice a lot of performance and have an extremely secure version of ASLR, implementation of ASLR. Or you can sacrifice a little bit of security for performance, for a lot of performance. And what we did is we took PAX's patch or we looked at his documentation and we went the performance route, which is the route that he goes with that has withstood the past 13 years. So what we do is we use deltas. We have calculated what we do is we, when a process executes, we generate three different deltas, which you saw from those knobs. The M-map delta, the stack delta, and the exec base delta. And so these deltas are applied in different places. So these deltas are calculated once and anytime you call M-map in a specific way, the delta is applied. So we're not consistently, for every single mapping, we're not consistently calling into the pseudo random number generator. That is one way to do it, but that would cause major issues with performance. Your computer would slow down to a crawl. So using those deltas helps us with performance and we do lose a little bit of security there, but it's negligible. So PAX's implementation does the same thing and it hasn't been defeated yet. Other than blind drop is a technique to defeat ASLR. There's no real way to defend against that except through other completely different mitigation techniques. So one of the problems with position independent executables is that they set their exec base in their headers to a null. So what happens is when you're calculating this delta, zero is a completely valid random number and so our implementation guarantees that null will never, ever, ever be used as the exec base. So we guarantee that null mappings will never be reached and so once we have this ASLR in the base system, once it's been fully upstreamed, we're gonna next work on reworking that PI support that we had committed and reverted before. We're gonna rework that and redevelop that. So how to use it? First of all, you compile your kernels so you need a custom kernel and you have to compile it with the PAX ASLR option. By default, because ASLR touches a whole lot of different places in the Linux kernel and especially since it's per jail, we have decided to make it opt-in by default. So you have to, well, not opt-in, you have to compile a custom kernel. It is disabled by default in the generic kernel. Once you do that, you'll get this, you'll get the tunables that are set via the bootloader.conf. So if you need to change these tunables, you have to reboot, which is really good. If you're an attacker and you wanna turn ASLR off, you have to reboot, which is probably gonna cause Nagios to yell at the system administrative team, the DevOps team, and it's gonna set off flags on the network. And there is another kernel option, the PAX Sys CTLs option, that allows you to have these knobs exposed while during runtime, so you don't have to reboot, but it is less secure. So when you do compile your kernel with the PAX ASLR option, you have to, it is enabled by default. So ASLR will be enabled by default. And child jails will inherit the parent jail settings. So you know how you can have multiple levels of jails where a jail might have a child jail. The child jail will inherit the parent jail setting. So if you have ASLR turned off in the parent jail, then when you boot or when you start the child jail, it will start with ASLR turned off. So to add support for applications to be compiled as a Pi, you have to compile them with certain flags. The C flag that you compile with is dash F Pi, all one word and the Pi is capitalized. The LD flag that you have to set is dash Pi with Pi all lowercase. So our ASLR implementation is just a very basic implementation as far as what, as far as how far along it is. I am currently researching how to randomize PS strings and the VDSO. That's gonna take a lot of work and changing and randomizing PS strings might break ABI and API. There is potential for that. I'm still researching it, but there is potential for that. It's a major change and it needs to happen. Otherwise, the ASLR implementation won't be 100% complete. The VDSO needs to be randomized as well because even though it's tiny, you can still generate maybe a couple, a few Rop gadgets out of it. And one thing that OpenBSD does that I really like is that they randomize the order of loading shared objects. So I really like that. I need help with ARM. I am kind of a busy guy. So I've been trying to learn ARM in my spare time, but my spare time is limited. So I haven't been able to fix the bug. I know what's going, I know the symptoms, but I don't know the cause. We need a lot more people to test this. I've done a few calls for testing on the mailing lists and we've gotten some good feedback. I've been running our ASLR patches in production for over a year now and I have had zero hiccups, zero problems. So we are at a stable point and we have a nightly cron job that makes sure that it merges still, that our work still merges in successfully with free BSD head. And of course, once ASLR is completed and PI is completed, we're going to work on porting over more GR second packs features. So the Hardin BSD project, we, Oliver and I, started this. We put in some of the foundations of it late last year and we made it official just a month or so ago. The Hardin BSD project is a fork of free BSD and it's pretty much, it aims, its goal is to serve as mainly just a staging area for us to do our development of these security projects and have just a place to wait for these patches before they're fully merged upstream. Now take that with a grain of salt because there are some things that we are not going to upstream. There are some changes that we just, it just doesn't seem like a good fit for the free BSD project as a whole, but does seem like a good fit for Hardin BSD. So we've already implemented one change and that is a CIS CTL knob that allows you to disable the map 32-bit functionality for AMD64 because that can be used and miss and abused to, to and may cause some security vulnerabilities. We are slowly becoming a more complete downstream distribution of free BSD. We're working on getting an automated build infrastructure. We're about 90% complete there and we're working on doing weekly Poudreir builds and nightly builds of head. So we have five developers and three of them are active daily. That would be me, Oliver and David Carlier who is in France. So Hardin BSD is coming along great. We have Chacha now implemented like what Tom was, Ted, like what Ted was talking about or not Ted Theo. Theo was the one talking about it. Sorry, too many things going on in my brain right now. Theo was talking about Chacha and how they replaced their Arc4 implementation with Chacha. We've done the same but for free BSD. So we are active daily. We're doing a lot of things. We've gotten quite a few patches upstreamed already to free BSD. David Carlier has been doing great work in getting his work upstreamed. So I want to say a special thank you to Oliver Pinter who's been an amazing person to work with. He's the co-founder with me on the Hardin BSD project, an inactive developer. And he was the person that originally started developing ASLR for free BSD. And I came in a little bit late to the project and added cool new things. And Danilo isn't one of the other developers for Hardin BSD. He has been working on another exploit mitigation technology called SEGV Guard. And Ryan Steinmetz, he's on the ports team. He's one of my coworkers at Cisco. And he had some really great ideas for integrating Pi support into the ports framework which I have not done yet. But he had some really awesome ideas there. I'm gonna murder this name since I'm American but Johannes Mexner, he convinced me to do some stuff about publicizing the ASLR project and to Soldier X for donating hardware. And so thank you very much. Do we have any questions? All right, well thank you very much for coming to my presentation. I really, really appreciate it. My slides are up on GitHub. So they're just a text file that you can read with any text editor. So go ahead and visit my GitHub if you want slides. There's references for some of the vulnerabilities and weaknesses in different implementations of ASLR.