 Wow, I I wish I hadn't said that to him Yeah, what I was talking about before I came up is that this year was the third black hat talk I did this is my first at Def Con and I'm a thousand times more nervous about this You know I've been coming since about DC 10 and I'm always amazed here. I always learned so much And I'm really on and really stoked and really Amazed to be standing up here and a little freaked out. So I'll do my best Sorry for the black hat slides. I suck I was gonna put DC logos and I was up way too late last night. Sorry So who am I? I'm a security consultant Which means that I deal with a lot of people who get owned That's kind of a lot of the job if you do this stuff for a living I work for a company called spiritic technologies, which is in st. Louis We do forensics a lot. We do incident response a lot So like say deal with people who get owned a lot and weddings funeral supremacists. I Like unsolvable problems. So to me defense is a little more interesting You know, I have to deal with the other side too I think you know people who are who really understand this stuff understand it like the sort of binary distinction is a Little bit simplistic. So my hat colors fuchsia Um Something that I want to say here. I've talked to a lot of Especially in the past couple of days a lot of people who develop exploits a lot of really elite really really smart really really awesome people I'm not one of those people This is my attempt to understand this topic as a normal human so The picture of me right there actually just to maybe help you out with that is Me running the New York marathon and I finished kind of somewhere in the bottom third And this has been kind of a marathon to sort of my attempt to understand this stuff And hopefully I'll kind of come a little closer to the middle of the pack. We'll see So yeah, I mean basically like right now with Vista You know, we're really getting my coward and these guys shouting from the rooftops that You know buffer overflow zero days, you know that there's going to be a lot of new stuff That's supposed to make this stuff a lot harder to do You know for me, it seems like we're in kind of a flailing death loop in the security business of Patches and signatures for sale on a subscription basis and things never really seem to get any better Did anybody go to Bruce Potter's talk? Is that been yet? Yeah, I mean basically, you know to me the security industry is kind of a racket They really don't have an interest in making anything any better in the long term or really getting to the root of the problem So this is kind of for one very specific kind of attack vector This is kind of my attempt to understand kind of the root of the problem. So So basically what we're talking about I get asked by a lot of people like what's your talk on and I'm like, oh shit ASLR, New York's X-Tax, Probeleys, Canaries, Access Control Models and So it seems like the prevailing term that seems to make sense is exploit mitigation That seems to be kind of a you know pretty easy way to describe what this stuff is So it's a range of compiler OS features library features that intend to make successful compromise a little more difficult One of them kind of the main aims and You know really that's kind of what a lot of this stuff is about is to make mass exploitation a little a little less difficult It isn't necessarily something that's going to protect a You know concerted effort to go after a unique, you know a single system, but it does kind of make Things that are sort of reusable a little harder to do And then you know sort of fundamentally a lot of this is about limiting Our exposure from overall kind of memory corruption based attacks Which is kind of a blanket term to describe You know stack-based overflows heap overflows return to libc all the you know kind of all this stuff So Yeah, so we're pretty much talking about no exec stacks a slr canaries Some compile time stuff a lot of these things are compiler extensions and I'm gonna talk about a couple other kind of containment models to Yeah, so again if you're elite you're in the wrong room Go somewhere else Let the humans and the normals talk for a little bit, you know this is basically just my attempt to understand this stuff and Some of the implementations, you know that are out there and you know like to say this is something I kind of got interested in about six months ago What got me kind of on it was I talked about this a little bit in the paper was working a big yellow outbreak and Looking at that in a couple of the recent windows exploits where it was like well Wait a minute aren't they telling us that you know, this is all fixed now We've got the GS extensions to visual studio and all that and You know, this is supposed to be solved. We've got depth, you know So that we're all supposed to be safe. It's all supposed to be so much better so Just to kind of like rewind way back and this has been my attempt to understand this stuff Okay, like ten people know who these guys are at least right Anyone be a lure No All right, I'm just not cool enough to did somebody say it Yeah, it's uh, it's actually I looked for K&R. I couldn't find a picture of K&R together So this is Thompson and Richie Sorry, so but you're close you get a cookie The yeah, and I think Richie is the guy with the Phil Collins kind of hair, you know with the bald on top deal But you know, I mean I think something fundamentally to this whole kind of problem and you know, there's On if you read Joanna Rakowska's blog, there's there's a Entry they were talking about you know game over like how do you how do you get past this stuff in a fundamental way? And I think kind of the prevailing Thought is that we really need to change the computing model and kind of look at some new like different ways to approach this But you know K&R when they were designing this stuff Your adversary your attacker that's the guy at the other teletype right so you can elbow him and say hey cut it out Do you know so now it's a it's an entirely different model from what they ever expected things to be and You know so fundamentally the class of bugs has been around you know longer than you know probably almost everyone in this room You know at least the 19 since the 1960s We've kind of understood some of the stuff in terms of high-level languages and how they deal with things It is Something that's kind of intrinsic to the von Neumann model. So von Neumann Kind of created the data code abstraction. So when you are back in the early He was a man patent project guy and he was involved in like Univac and some of these things and on the early early systems to get new code You had to re-solder right? I mean that's how it worked and that was less an elegant way to do things So von Neumann kind of came up with the data code abstraction So you have you know code and you have instructions and then you have data and It's the breaking of that membrane between the two that is what a lot of this stuff is about So yeah, some of the cool. I was like Fandango on core. I don't know why they didn't take off You know like MSO 546 Fandango on core and ISS or IS You know would be kind of neat but everybody kind of went for buffer overflows and it's a less than perfect term and if you talk to a lot of people They'll talk about the specifics that it's you know, it's not the best definition But it seems to what we all kind of use to refer to it so in trying to go back and like understand like how far back kind of the stuff goes that the Morris worm was One of the vectors that Morris used to spread was a stack-based overflow in finger D in the get's call And it's actually bug ID number two on security focus Bug ID one was send meld bug which was like the other vector and it's like yeah, okay Send meld bug first one in bug track makes sense. Cool. Okay and here's what's interesting in Jean Spaffer's analysis of it He says that you know the lack of bounds checking and see the get's call and the scan f call You know and some of the other unsafe calls and see should be avoided So the answer is yeah, we've been we know about this for about 19 years at least that somebody's quantified it and said Hey fundamentally, this is a problem So between Morris There was there were a lot of system vulnerabilities back then that were not that complex. They were things like Really bad coding, you know stuff like you know ending entering bad input I think there's like a vax bug where it's like hitting enter a couple times or something drops you into a login like silly stuff like that so Things got a little better on the basic stuff In about 95 Thomas Lopatec found a stack-based overflow posted at the bug track in the NCSA HDBD and What was kind of cool for me about it was he said hey, this looks like the Morris worm bug, you know this is the same thing and The thing I guess I would say about Lopatec was the reason that was so much more interesting Right was that it was this we were just starting to begin the commercial internet and all the interconnectivity and all these other connections between different networks and it was like a Whole different problem that right and it's a problem. We're you know, we're all sort of getting our brains around still right so Mudge wrote a paper in 95 that was kind of like one of the first ones actually desperate eight elf one It's really like kind of like scratched on the back of a napkin But it you know, he describes it as a note to himself, but it's how to write before overflows You can find it out on you know, if you're a antiquarian like I am you can find it in a lot of places So and then alif one Obviously has Well, I already asked the elite people to leave but how many people who have read smashing the stack is that I did it Qualify as elite. Wow. Oh shit So like I say, this is just my attempt to understand I read it like a long long time ago and then kind of got into I like say kind of talked about this in the paper But I got into the security industry, you know for good or bad You know, so honestly like most people in that business with the exception of the really cool really elite people here I'm not writing exploits I kind of got my hand around it a little bit kind of started to understand it and then I Circled back to it like about six months ago and I was like, okay, I've learned a little bit I can't understand a little better now, but you know, he talks about memory segments talks about the layout of the stack It's always a good place to start And you know the data code abstraction You know kind of really started to fine-tune and describe like creating shellcode some of this kind of stuff Then solar designer In 97 just a little bit, you know around the same time There was a lot of activity and kind of understanding this problem around them Talked about return to libc because he had authored a patch. There's no execs. No exact patch for Linux kernel And he said hey wait a minute, you know, I broke my own stuff You know, here's a whole nother kind of method Which is just basically pre-loaded functions libraries and things like that in memory. So And then 99 the woo-woo guys You know the woo-woo and heap overflows paper was kind of one of the first really detailed papers on heap overflows There were some other ones Around the same time. So if anybody wrote them like don't mean to not give credit But kind of the same thing, you know talking about That the heap is another method It's another area of memory and so when you're talking about overwriting memory memory corruption vulnerabilities, you know, there's basically kind of The really the kind of the three main targets that you're talking about are pre-loaded functions Doing execution on the stack or writing to the heap so Okay, so I like I could talk about this the whole time and Maybe you'd all fall asleep to me. It's kind of interesting stuff that kind of the history of all this But kind of the point is that the approaches kind of have evolved and you know There is a lot of a lot more complexity to this but sort of fundamentally you've got two or three places that you're targeting That's kind of what this is about the vectors You know kind of are the same for exploitation. So This is a national vulnerability database remote buffer overflows. So just remote no locals Up to 06 because that was kind of the end of a year and there are some questions about the stats They use you know, they count different Linux distributions separately and all of that but you know fundamentally I mean this has continued to be a problem. It's continued to be a bigger problem You know and I guess for me, you know the reason I'm you know, I really would like to see us Start to concentrate on you know some of the other problems Out there in terms of you know end users desktops You know the client and and all these other areas and it's like we're still stuck in this like 90s loop You know, so this is you know, this is old stuff And in fact actually like I find when I talk to people that work on this stuff It's kind of boring anymore like oh network, you know network base, you know Overflows that's dull, you know But it still goes on it's still a very common method of exploitation and we still see lots of bugs in it. So So, you know at a very very high level and again, this is just my attempt to understand these things What you've got is unexpected input an unchecked allocation of memory somewhere you write to the stack right to the heap You call pre-loaded functions you move execution to that and you end up with control execution flow I mean that's that's sort of fundamentally and the best way I ever had it described to me like Quite a while ago was you know ten pounds of crap in a five pound bag You know, so you you've allocated to memory and then there's more input than was expected So kind of the first place that things went in terms of dealing with this stuff was You know the no exact stack stuff, which is sort of saying back on like the von Neumann stuff There's a data layer. There's a code layer. There's data segments code segments, you know, so let's keep them separate so So the you know basic kind of concept of a no exact stack implementation is That you have a data buffer where you take input from programs and and allocated memory that you're using and You make that segment kind of read write and you have code segments that are there read execute So just you know keep them separate so The Solaris stuff and this is You know what's funny to me is I used to do a lot of Solaris hardening and Solaris work like a lot of years ago And people used to say oh, you know, we're so cool and on Sun because we've got the no exact bit, you know, and You know the truth is that it really did almost no good I mean it's been described as a speed bump, you know by itself but you know that was kind of one of the first implementations and then You know nowadays we kind of circle back to that on the AMD 64 platform and Specifically it actually is its page address extensions which give you a more kind of granular paging model in memory And there's a there's a bit that's a bit 63 then you set to zero or one for a given page and that's kind of sets the execute bit something that is Pretty important and we'll get to it in here in a little bit is that By itself the CPU is not doing anything You have to have operating system hooks into it and the implementation of how you hook into that It's pretty important in terms of how sound it works as a as a protection mechanism So the CPU itself is not doing squat. You know, if you don't have hooks into it. It's it's just sitting there So and then on the emulation software stuff Solar the no exact stack patch stuff the stack patch for Linux was kind of the first stuff OpenBSD is then the WXRX stuff Exec shield is red hat implementation packs, which is very cool and then on Windows you've got the dynamic execution prevention, right and I guess on 64 versus 32 You're really typically on a 32 bit platform. It's it's really just in software So what you're really doing there is just kind of drawing a line in the sand and saying this sort of section of memory this segment and You know they divided it depending on the implementation. They divided in different places, but it's saying this area memory is for data This area is for code One of the things about no exact stacks and I have a friend as a Java developer And he always gets annoyed with me when I talk about this and that I'm interested in it because he's you know In Java, this is what you do all day long is create code on the stack And that's what a jit compiler and things like that do is they actually break the model, you know, that's by definition That's what you're doing. So one of the things about that is that the different operating systems have had to have a Mechanism somehow to exempt those things And allow them to not sort of play by the rules So With the no exact stack the vulnerability is still there And like we kind of talked about heap and return to libc and things like that You've just sort of reduced what's possible. So probably the most important thing is return to libc You Basically call a pre-existing function memory something else that's loaded So the reason it called it gets called return to libc is that libc includes a lot of common calls that will allow you To exact commands or or things like that system in SH was like always the example in some of the early stuff Most of the things that talk about you know breaking out of an X to sort of come down to this Another another kind of method for this is to call the mProtect function which allows you to say this for this chunk Of memory don't make it Don't sort of apply the protection. So you're exempting yourself out with mProtect and We'll talk about some testing tools later, but Basically if you have the ability to call the virtual protect function the mProtect function these sort of Allow you to exempt a given a given chunk of memory from all the restrictions. So Return to libc does require you to have the known address. We'll talk about some of that later heap-based overflows you know the like say the Libc is not the only the only target stack is not the only target He based off is it's kind of seems like lately of more interest and Did anybody see Alice's talk the DL Malik talk? It's after me. Oh, yeah shit. Okay. He's like way cooler. So the elite people can come back then So yeah, so stay here stay here. I actually want to ask him about something I'm gonna get to her in a little bit in terms of heat-based up Something else is a parent post a body Came up with what they sort of call multi-stage overflow So the idea is you know when you do a no exact stack. It's a very specific set of conditions That you're protecting against which is basically like say sort of data jumping over to code And so what you can do in the case of theirs is you overwrite a function point at first and you point to an address and then You load shellcode at that predefined address later and so you didn't break the model necessarily So you didn't jump from data to code. So it's still a method to circumvent that Scape and skywing and this is kind of interesting to me Have a paper it's it's from a maybe a couple years ago talking about ms's depth Protection a lot of people were interested that when it sort of first came out Dep is configurable in the case of max ms's stuff remember we're talking about how jit compilers and things Require the ability to construct code on the stack. So you have to find Ways to exempt them out of the model. So what ms does is use the process execute flags. Oh What's given skywing found was that there's a there's a value there Mem execute option enable disable so if you flip that bit you've just allowed yourself stack execution And so then you can pop back in so pop back through that and sort of opt out of that So one of the things they talked about in there is setting the no execute bit is always on in the boot I and I it'll break a whole lot of stuff unfortunately But that on especially on systems that don't have sort of all the other protection. So like 2003 and XP This is probably the best you can get is to set it to always on if it's set for opt-out or it's set for opt-in It's kind of mood. They're basically the same thing In terms of the fact that you can set that set those bits and let's say jump out of the model Doesn't matter Pax uses an elf header and lets you set bits on a file and say like this file is blessed to do this by itself And I think maybe that might be a higher bar than sort of doing it in memory at low time One of the probably biggest problems with all of this stuff not just actually no exec stacks But the whole thing is that this is an opt-in opt-out model You can pass flags to the compiler to opt out of it. You can Find yourself disabling it when you set optimized flags and things like that So you have to be really careful read your compiler documentation and things like that and understand exactly what you're doing It's pretty easy to turn this stuff off without realizing that that's what you've done And then there's other mechanisms that allow people to opt out Skywing has on his site if you if you check this out the no exec hall of shame It talks about a lot of apps that break whenever you have stack execution turned off 100% Me personally like running that With that bit set, you know firefox acrobat java, you know, we'll just barf and they'll shut off and then you have to start them back up It's something that I thought was kind of interesting. I used to use an app called secure stack, which is a No exec stack stack implementation a long time ago that actually ran on on like nt4 and and windows 2000 before they had anything else for that and I was doing a large network that had a bunch of veritas backup exact client setup and This admin was pushing this update They have some kind of ability the hot patch like the drive the the drivers and the services They go like push update client now, you know from the admin console and it like pushes us out and every time Every time you ran that it would crash because the cure stack was saying no you can't execute on the stack And then you know a couple years later You had some stack-based overflows and in backup execs. So, you know, maybe it was shutting it off for a reason You know somebody more qualified than me could probably say that So sort of the next step was to to check for memory corruption Around the same time that that overflows and sort of all of this stuff was kind of very common As the as a exploit vector around that same time Crispin Cowan who hasn't talked tomorrow, I think in the guys from Immunix Develops that guard which was kind of an early implementation of the canary approach and so basically what you're doing is For the return address you're setting a canary value in the stack and this If this value has changed that means that you've overwritten memory So in function prologue at startup you sort of stamp it with this with this canary word and then At function epilogue if that values no longer there then you call exit and actually they called Different calls through the different limitations of it, but fundamentally you're shutting off if the canary value change So like say it's kind of tripwire for your stack is the way I sort of for me understood it Later versions of stack are kind of added different ways to do the canary stuff There's been there were a number of different papers that talked about problems in the way they did canaries, so The they've tried a whole bunch of different approaches We'll get to actually propolis which is probably more interesting because it's more common these days and probably the most widely accepted approach for this So yeah propolis is actually What was integrated into GCC for one? pretty recently The open BSC guys did a lot of work a few years ago back porting it for the 3x GCCs It was embraced and extended by MS as the slash GS compiler flags from what I understand The latest version of visual studio is a lot closer to a full-blown propolis implementation The early stuff that they did was was just kind of kind of a sort of a Kind of I don't want to say how fast Kind of a step into implementing that The in the like say the GS cookie in visual studio is going to the same thing as a propolis guard value and Yeah, her rookie likes to call it guard values stack arts canaries, you know, and he he says it's a guard value and he wrote it So I'm a tickets word It is a it's an extra of the of the pointer in a random value and then you store those somewhere off the stack He moved beyond the return address, so you have Sort of all registers we'll get to that in a minute about about stackard But one of the things that it did especially initially was just protect the return address variables and razor the bottom arguments at the top So then it helped me understand propolis is you know You know whether I'm an exploit writer or any of those things I consider myself a hacker So I don't like anything with police in it So, you know, it kind of made me cringe when I read the name of it But propolis is actually what Bees used to construct their hives and so it's the outside of the hives And so really what he was using in naming it that was describing sort of a well-ordered Stack and and a well-ordered address space in memory and so that helped me understand a lot better And I felt more comfortable about the name then but What propolis does and this is totally ripped from a slide that her rookie did at Kansak West So if you go get his slides, they're like we cool it in mind, but You're taking some of the more commonly overflowed buffers so arguments are typically things that you're going to see arrays That are things that are pushed in and tend to be places where buffer overflows are you know where you're inserting data and He laid out the stack and in sort of a cleaner way than what you would typically have so in inserting data Into the stack and and overriding a memory segment typically what? Overflows do is to overwrite both the array The buffer and then the return address so you kind of have to in order to do that They have to be sort of adjacent so by laying it out in a better layout It makes it substantially more difficult to exploit stack-based overflows So that was to me that was more important about propolis than maybe the guard values You know, that's why I think it Developed a lot wider adoption and then stack art because it was a sort of a move to a whole kind of a better model a better approach So kind of an interluded canaries which relates to Alice, so I'll try to maybe stick around for for his stuff is Something that is not too widely adopted that's out there as heap canaries There are a couple of limitations for that Contra police is is one attempt that the open misty stuff has the g option to mallet comp and That's not enabled by default because it breaks a lot of stuff But what this does is apply the same thing to the heap so in talking about you know The heap as another vector for this stuff what they do is place the kind of the same thing canary values and guard values at That's sort of the beginning in the end of of the memory allocation So and then wkr. I wish I knew his initials But he has it's one of the guys from shellfish a couple of years ago And he has a a heap guard implementation for DL Malick Now the thing that he says on his side is that he's discontinued development because it's supposed to be integrated into DL Malick So that's why I'm kind of curious about Atlas's stuff because From what I could tell it wasn't yet in DL Malick, so maybe Maybe it's not actually out there yet, or maybe it's totally irrelevant. So that's why I'm gonna stick around anyway So the main thing about canaries was that If the canary is the is the only element to protect Against corruption memory. It's the defense simply becomes sort of as good as a canary value. So Gerardo Richard was course that guy He had a paper on a lot of different methods to defeat Specifically stack guard and stack shield and some these other things and basically what he was talking about is if if Other addresses aren't protected Or if you can find ways to to overwrite things like stack frame pointers other places in memory It's it becomes a way to defeat it Bulblin killer have a there's a frack paper from a while ago that was Specifically pointing out probably the fatal flaw in stack guard, which is that it just protect the return address So they they found that because of that, you know, you could write pointers in other places You could write over other areas on the stack and it you know You're just sort of doing what was the most common method to exploit stack-based overflows Which is to overwrite the RTA, but it's not the only way So another thing is you can area somewhere in memory if you can read that canary value somehow that may be of value There are some methods to to kind of keep it off stack and And so things like format string bugs prop prop man and things these info some kind of info leakage might give you a way to disclose that So and this is what? Especially Vista, there's a lot of hype about there's a lot of discussion about with Vista is you know if If you look at most exploits they target kind of known addresses So if you look at exploit code, they'll have you know, this is this is you know, if you ever Run exploits nobody does that around here and stuff. You'll see You know, this is the red hat version. This is you know for Fedora core 5. This is for whatever well It's pointing to specific addresses in memory. So with Address-based layout randomization or ASLR what you're doing is you're randomizing that stuff packs is Really probably the first people to come up with us. I think I think there's a little bit of finger-pointing and stuff They have probably the most robust implementation of ASLR out there So you randomize user land case that And map calls things like that. So then I like about packs is it has a lot of tunable bits So you can flip things kind of on and off And also CH packs or packs control let you do that on a per binary basis. So it's more tunable When you look at the stuff that open BSD does it's all kind of turned on and that's what you get So if it breaks things Sorry, you know There are some similar bits for net BSD and free BSD and I actually got some slides on that later If you're interested in checking that out on other platforms Exec shield is red hat implementation It does some stack randomization things like that. I don't know why they didn't just use packs It was out there. It was already pretty widely supported and instead they sort of decided to build their own thing So that doesn't make a lot of sense to me I think it's one of the problems with the open source world sometimes is that especially the sort of corporatized open source is that Even though there's things in the community people will still develop it open source But they'll still do their own thing so they can say this is you know controlled by a red hat developer So this that adds a random Xe and DLL loader varying degrees of entropy and randomization Packs open BSD some of these have a lot better randomization than Vista For apps to utilize this internally. There are some pilot flags that have to be passed to it I was talking to a guy from MS The other the couple days ago and he was talking about how much he really hated The slash dynamic base flag because it makes Crash dumps really hard for them to understand and I think there's like some developer backlash about it But in order to to really take advantage of this stuff. That's you have to pass flags with compiler All the White House did a talk a little while ago Talking about some of the weaknesses on the heap Heep addresses and the heap randomization of Vista is much more predictable Than maybe it should be and I think there's some discussion that they're going to properly correct it in a couple revs so position independent executables are a way to To take advantage of some of the ASLR stuff in a given Xe and that's kind of required to really take advantage of ASLR fully so if DLLs and libraries are randomized that helps but it doesn't it doesn't get to sort of all the way there unless you're building things That are fully position independent themselves. And so basically they find the global offset table They go somewhere random and so at each run a given Xe. It's it's sort of less predictable John Moser is a guy who's been trying to get a lot of this stuff integrated into Ubuntu He has made a little progress probably not as much as he would like But he just a you know his guesstimate is that if you take stack random bits and MF random bits You know, it's a one and two to power to the power of that to predict and address So you're relying on randomization to make these things a little tougher to explain Pick pie Dynamic base, you know all these things are like say they're kind of key to a full blown ASLR implementation if you don't have If you don't have position independent executables the ASLR by itself doesn't really do you a whole lot of good Or at least as much as it would with with both bits So on a SLR basically what we ended up with was The the randomization itself becomes kind of the the key sort of factor So somebody that I thought was really interesting is a guiding Hove off Shackham And he's an Israeli cryptographer who looked at this stuff and said well, hey, wait a minute This is bad crypto, right? And this is just kind of you know weak crypto So what he did a paper on packs on a 32-bit platform? So this is a while ago But what he did was build a Apache that was vulnerable to You know a couple different things, but what he did was attempt to do a return of libc on that and Guess try to guess the offset of the system call And what he found is that an ASLR protected Apache he could he could exploit that in about 200 seconds The problem is that Apache restarts respawns Every time that it loads So if it crashes typically when you're when you're taking advantage of Buffer overflow you're crashing a service So if it restarts every time then you can continue to you continue to keep trying till you guess the correct address In somebody tells me in Vista. They I think they do three failed Three failed startups like you know service restarts three times and then it stops And GR sec which is some other technology that integrates a lot with packs They have some bits to do that to do the same kind of thing. So if the service crashes In memory, it'll it'll restart X number of times and then after that you stop So that sort of makes this a little more difficult and I think actually with GR sec they They pause like X number of seconds again So that kind of makes us a little harder to brute force But like said I think what was kind of neat about this guy was he sort of looked at this Is like like I say kind of a weak crypto system and pointed out some of the problems with it He has a paper that just came out that I'm just going to point out because I thought it was pretty interesting. It's a Look at a way to do return to libc with no function calls So he has this if you go out just Google for like hovab shotgun I think it's hovab.net is his domain. He just published this a little while ago What he does is he I'll call you back what he does is scan through Loaded libraries and come up with a series of what he calls gadgets Which are little bits of code that do different things and then kind of chains them all together ties them all together To to end up doing execution without actually calling like a function And so he has a method to scan memory for all these pieces And so it's it's not really specific to stack protection is just kind of interesting because I've never seen anybody Come up with an approach like that and it's kind of a whole different problem from some of this stuff It's something else that they just sort of occur to me and looking at this stuff is that Shack them, you know on the heap in Vista you have weak randomization When you're looking at something like a client site exploit where potentially you can restart as many times as you want Something that's browser-based for example, you could just keep starting over starting over In say something in a JavaScript. It's in a browser. Well You know if you're looking at weak like say Vista having pretty weak randomization on the heap It would seem like maybe this would apply Ben Hawks did a talk at Rusk at Ruxcon a little while ago And he talked about a method called code access brute forcing So what he does is use a series of sort of unsuccessful reads. So again in ASLR being mostly a method to protect against return to libc preloaded functions in memory have sort of It's you don't know where it starts and ends, but it's still the same size So like the system call is kind of roughly the same size on a given platform So if you can kind of poke around eventually you can infer that address So he actually did a bunch of work against open BSD and and look at that and also things that pre-link will potentially Give you ability to to get some of those locations as well All the White House I mentioned him a couple of times. He did a talk at actually black hat DC and He did it here in Vegas as well. It's out there because it was that black at DC You can get it on the site. So it's out. It's out at the black hat site And he did a bunch of series of kind of regression tests against Windows Vista and Looked at how efficient the randomization is and he found the probably the most interesting thing that he found was that when you use the standard C and protect or sorry call MS has like their own And he found that when you use the the ANSI C1 it had better randomization than when you used MS His own recommended call. So I thought that was kind of funny, but What he what he found was that the randomization was substantially more predictable And he's got these really neat Visualizations of it that make it really kind of easy to understand because you can see this kind of Sort of mostly flat line as he went through and and did what he did was do a series of like Hundreds of reboots on a Vista box and then look at the addresses and then map them out And so what he found is that like say the crypto there is not so great So sort of exploit mitigation cliff notes Like say no exact no exact stacks and NX if they're configurable at runtime. They're pretty useless There's lots of other ways. So in and of itself. It's just about worthless Dave Maynard called it a speed bump a couple of years ago. I think that's pretty accurate SLR bad cryptos not a panacea by itself Memory leak bugs and things will allow you to find other ways Again canaries bad cryptos not a panacea so All rights to memory space require protection And I think that was the lesson from Stackard was that just a couple of addresses doesn't do you that much good The best practice today, so this is so like all these kind of have flaws right but basically what the consensus seems to be right Schneier says security in depth, you know the The aggregate of a series of imperfect controls is a better control, right? That's the hope So, you know the mesh model is another another sort of expression of that It's a combination of all kinds of different features that maybe may not work so great in and of it of themselves But hopefully the aggregate of all of these together gives us some modicum of safety And what I can say again, you know this thing just sort of my attempt to understand this stuff is that a lot of really smart guys So, you know go go by the immunity booth and talk to Dave. I tell his they're really cool guys in general And you know he says hey this stuff is pretty tough to hit We'll actually we'll get to this in a little bit like what seems to be the main problem now is inconsistency and sort of problems that Different pieces of software have in implementing all these And some of the ability to opt out of these things but sort of the aggregate of all this stuff so you've got a dress-based randomization you've got a pretty consistent no executable stack and You've got some kind of canary method to check for overrides and corruption and memory like the aggregate of all this stuff is you're in a pretty good spot and Like say that that seems to be the consensus is that you have if you have All of these things and they're turned on consistently and it's turned on and all all of all of your code And it's all built that way Potentially what you'll get and this is the hope right is that if you're running vulnerable code and you don't know about it Because we don't unless Somebody else has a lot more time than I do We don't read every line of every single piece of code we run It's not possible unless you do one thing or unless you sleep a lot less than I do and I don't sleep a lot anyway, so The intent of all this stuff is that we'll have some level of protection against these things and Give a way to kind of contain this stuff so 19 years later, we're just kind of getting a handle on this so what else can we do to raise the bar? Static code analysis Something that especially if you run open source stuff something you probably know about is the fortify source bits for GCC Dash d fortify source equals to will actually replace dangerous function calls and things like that and look for Mistakes and actually the one thing I found was format string bugs which are not that common anymore from what I understand but When they are out there, they're pretty ugly stuff Because they sort of allow arbitrary reads and writes to memory things like that Dash d fortify source equals to will actually catch some of that stuff in compile time. So that's pretty cool the covariity project in in Which was a project that was funded by DHS Went through and did static source analysis with obviously covariities commercial source code review product that they want to you know promote they got a contract with with Department of Homeland Security to go through and Perform static code analysis on sort of every major open source project. So they went through Apache and You know binds and mail lots of other things something kind of that I thought was pretty sharp was Ben Laurie pointed out that It's really nice of the Department of Homeland Security to pay a commercial company to find bugs in open source code It'd be even nicer if they paid open source developers to fix them so what you're finding is a lot of a lot of this stuff and then They're not disclosing it They're working with the with the particular project teams to address it But you know then they have to have their resources to deal with all the bugs that are found Sort of a limitation of static code analysis obviously the the single best way to find any given bug is is To actually do source code review by a human being you know line-by-line and yeah, and there's of course Discussion about things like fuzzing all this other stuff, but you know rice's theorem Says that for I guess for a given problem set, you know, there's there's a if it has X number of answers You know, it's it's not predictable you can't fully fully predict the Yeah, I actually suck at rice's theorem. I'm gonna drop that but What made more sense to me for it was what I call rumpsfeld's corollary, which is there's no knowns There's no non knowns and we and there's unknown unknown So we know what we know we know what we don't know, but we don't know what we don't know We don't know so, you know, and that's when you're doing Static code review and things that's kind of the deal you hope that some of this stuff will will find all these things But you don't know for sure One of the other things that that sort of comes into this stuff is access control models It's not really a method to To actually stop memory corruption vulnerabilities, but is a way to sort of do containment So you have things like RS back to your security app armor SC Linux And there's a lot of contention in Linux about which is the best and what access control bottle everybody wants to do I'm just going to say and try to be agnostic and say they all have varying degrees of complexity And I won't mention which one is the most complex I think other people probably if you've touched any of this stuff You can guess But there are there are lots of solutions out there that allow you to contain what applications can do and contain where they can read write and Sort of even if you have expectation of given vulnerability, maybe you can't kind of Find access to other areas of memory or in other areas of the file system like that MS has a access control what they call mandatory integrity control model in Vista This is the thing you click allow allow allow allow allow one when it pops up So in then big iron Unix you have trusted Solaris and HPEX as a C2 trusted mode These are sort of other ways to kind of like to say contain execution based on I mean to contain file permissions and things like that based on user ID And then little iron Unix you know trusted BSD which is part of a free BSD from five up and then I Actually, I guess should mention that open BSD has the the SysTrace stuff, which is some other ways to to control What applications can and can't do? Mac has Mac now Apparently it's it's actually part of leopard It was I didn't find a lot of docs on it was announced it at the WWDC that it was going to be integrated and Then there's there's if you check on Apple site There's like no docs or if anybody's got docs on how to do this stuff in leopard You know, let me know There's some of that was an offshoot of a project called SE Darwin, which is an attempt to Kind of include some of the SE Linux features in the trusted BSD features into into Darwin Open BSD is as I think probably most people know then a lot of work with pro police WXRX So they they've got a lot of other things one of the things that the Open BSD guys ran into a lot of debate with the PAX people about is The mProtect function call Which like I say allows you to kind of say this this check of memory sort of ops out of the model Their their belief is that breaks positive compliance and that's all well and good But I like the fact that With PAX and GRSEC I can turn it off. That's you know, I'd like the option to say no I don't want that even if it breaks some of my stuff A kernel randomization is from what I understand out there if someone's telling you wrong go for it but Recently you've seen a lot of sort of kernel based vulnerabilities in open BSD and I think that's probably a factor PAX does do Some randomization of the kernel stack Free BSD there are some ports of some of the open BSD stuff to free BSD. So just Google for like SSP free BSD and There's a this guy to URLs out there. I'll have this the slides out Pretty soon. Sorry. They're not on the CD But this guy supported some of the stuff to free BSD if you're not doing that and you're running free BSD All you're getting is sort of very rudimentary. No exact stack. That's a The net BSD guys have been pretty active on some of this and they really have been looking at PAX and Trying to kind of add some of these features into net BSD So with Linux You know with the integration of propolis into GCC for one kind of everybody has some bits of this the Ubuntu guys There is a there's a offshoot of Ubuntu called Ubuntu hard and there have been a couple different Linux distributions that have been centered on some of this stuff The the Amunix guys the Adam act it at excuse me Atamantic skies that were working on some of these bits for for Debian But the two that are most active that are actually doing a lot of this stuff are the hardened Gen 2 project and Let's say Ubuntu hardened They've been sort of trying to move some of stuff and you go out to the Ubuntu site They have something called the Ubuntu security roadmap that talks a lot about this stuff and actually for me That's probably where I got most interested in this was just kind of reading through a guy named John Richard Moser Who's thinking about a lot of this stuff for Ubuntu? Like say in GCC everybody has at least the propolis stuff, but if you look through The bug reports for most of the Linux distributions that you'll see a lot of stuff about hey this broke my code So I did f no stack protector all so I just turned it off because you know something broke So actually what I will say is that that is one thing that that the open BSD guys are pretty Pretty impressive to me about is they've kind of said you know no we're gonna. We're gonna make this work. Sorry, so you know, it's pretty cool This the least explosive Ford Pinto ever So, you know, they've they've made up a lot of progress You know, I guess what I would say is they sit where some of the security Centric open source projects were about oh, too, you know, so that I mean that's really that's pretty cool When you consider that their commodity operating system that everybody you know They have to support thousands of different closed source applications that run on their platforms, right? So they have ASLR they have some basic position in the pendant executable stuff The biggest problem they seem to have is the consistency So there have been a number of windows-based vulnerabilities where You've seen things where people went through and said well, wait a minute, you know, why didn't this why didn't this get taken care of and it's been because It was compiled with different versions that a visual studio. They didn't have all the same beds or you know the The also like I say the ability on a sort of software basis to opt out of some of this stuff to me I think it's part of their problem Something you may want to check out if you're interested in stuff is that these guys wayness Make an app or in a series of sort of binary drivers that Allow you to have some ASLR for 2003 next P Which is not something you really get basically 2003 next P You basically just got kind of some of the GS stuff and a rudimentary sort of no exact stat OS 10 think obscurity So the 3% of the market share means that we're absolutely rock-solid and unbreakable It's true You get a no exact stack in the kernel because they deal a lot of their stuff kind of ties into previous D stuff and Darwin is coming for some of that. So you have basic no exact stack. That's it. No ASLR No pic no pie You know, I think that Apple is going to continue to have a problem with this until they really sort of take this stuff seriously Right now they say it's more about not being a very visible target. I think that that is why they can say they're so rock-solid so belt suspenders You know kind of both Every defensive measure, you know can be defeated in a vacuum and basically The reason that I got interested in this was that all the material that I could find was either written by somebody who talked And actually let me say with one exception if you go to the pack site those guys have this stuff very well documented There is there's a lot of really great docs out there of just going through how this stuff works And so if you want to start somewhere to understand it whether you run packs or don't go check that out because it's pretty cool but You know most of the things that I found either talked they were the room by somebody who wrote a defensive mechanism and said How unbreakable it was or somebody who wrote Or came up with a method to defeat that mechanism and sat said how there was no way around what they came up with so this is kind Of trying to kind of look at both sides You know bone product see we'll always get on One other piece that you should check out is packs test and Vista probe they're available for Packs test for examples probably built on just about every platform you can run this and kind of look at on your box You know, what do you have turned on and how much of this stuff is there? And Then Vista probe actually was written for Vista to look at some of this stuff And and it basically runs through like some simulated Exploits to kind of gauge your your how effective the different measures are so like you know stack execution with and protect without You know stuff like that and they try to predict how many bits of randomization you have for your libraries and executables so it'll tell you you know sort of where you sit and Like say same same for Packs test There's some debate about packs test on other security platforms, you know of is it sort of centric on packs, but You know it does it is about the only thing out there that you can sort of as an average person run and get some idea of where you sit I have five minutes Let me say just real briefly the the own the box own the box thing You know Where that came from was that I actually Sort of wanted to find out not knowing How effective sort of really being able to say unequivocally myself You know, how good is this stuff? What sort of I proposed originally to the deaf folks was that I was going to bring a box plug it in the network and build it with in my case like Genji Harden and all the pack spits and put some services and some app some apps on there that are sort of old versions and then When they decided that that was something they would want to promote I decided I didn't really want to make it about just me So I sort of asked lots of other random people to do the same thing And so it actually I guess what I would say if you've had any involvement with any of the people that have Sort of glommed together and are working on it. It's kind of become more like the own the anti-cardware project So not a lot of people wanted to bring boxes to get owned at Defcon I thought it was a good idea I don't know but So if you're interested in like old son IPX is in like an old next box and things and you have some some stuff It'll work on that, you know, it's sitting out there What I will say about my stuff is that I brought I brought a actually a pretty nice piece of hardware I'm running in my case like 1.3.37 of Apache that should be vulnerable to the mod rewrite Overflow and and open SSH some other things I Think really the reality is the people that are sharp enough to To actually look at some other ways to get around some of the things that I have turned on Probably not really interested in my like shitty $500 server So But if anybody if anybody wants to talk about some of this stuff and tell me why I'm wrong like that's cool That's about it. Thanks guys. Thanks for sitting through this win for Atlas