So my name is John Oberhide and today we're going to be talking about antique exploitation and to give you guys an idea of what this presentation is about so that you guys can leave last minute if you want to. We're going to be talking about Arnold Schwarzenegger and his various escapades across cinema. So if you guys aren't interested in old systems like Windows 3.11 for word groups and you're not interested in a presentation for shits and giggles and you can go learn something from a useful presentation, maybe go see Dan Kaminski's Talk on Track 1. But it looks like everyone is staying so you're either asleep or you're very interested. So again, this glamour before we get started here, this whole presentation is essentially me complaining about myself making this presentation. I made this entire deck in paintbrush which is not even as... Thank you, thank you, thank you. It's not even as capable as MS Paint. It's pre-MS Paint. It's the MS Paint that came with Windows 3.1 and I thought it would be a nice novelty to actually make the deck in the same program and platform that I was exploiting. So it's a little rough but it actually doesn't look too bad I think. I think I did a good job. So we're going to be talking about some old systems that you probably don't care about but that actually is surprisingly still in use. And just to start off, the premise of this presentation is similar to the movie Terminators where a machine or something is sent back in time to eliminate a target. And we are going to be doing the same thing, traveling back in time to eliminate the target except in our case the target is not John Connor or Sarah Connor or whoever. It is an older systems platform which is related to this movie, another of Arnold's escapades called Junior which was released back in 1994 and this movie is really a crime against humanity and sublimation of cinema and we have to go back in time to destroy it. There actually was an essay contest I saw when I was making this slide deck about juniors like JuniorBestMovieEver.com They held a contest to see who could write an essay about why Junior was the best movie of all time and since this is like an absurd idea in the first place it got all sorts of national press coverage and yet they still did not get enough submissions to even cover the number of prizes they were giving out. So it's very obvious that you know this movie just you can't even try to write about why it's the best movie of all time but we're going to go back to 1994 when this was made and try to stop it from being made or released. So give a couple little bit of context to you guys who don't remember that far back 1994 was when OJ got away with murder, literally it was when Nas dropped the Illmatic album, the best hip-hop album of all time it was also, I just heard this yesterday but I heard that Spencer Pratt actually was rumored to invent return oriented program back in 1994 so you know, Rob just keeps getting further and further back people are claiming that they came up with it but I heard that Spencer Pratt actually did, oh yes. Thank you, thank you sir. And of course in 1994 Windows 3.11 was released this is actually a lie, it was released December 31st 1993 but it's close enough to 1994 so we're going to call it that. So Windows 3.11 is our attack target we're under the assumption that this movie Junior was made using Windows 3.1 workstations which is probably also incorrect but for the sake of the story we're going to assume that. Windows 3.11 was a 16-bit operating system but there were some sort of hacks on top of it Windows 32S and also the Windows 16 enhanced mode which if you had a 32-bit CPU running in protected mode you'd have 32-bit memory addressing and also the good old Windows for work groups 3.11 was one of the first times that TCP IP was introduced via the WinSock interface. So it was a spectacular release and everyone still uses it on their laptops today, at least I do. So looking at what we would do if we actually were in this situation and we were going back in time what sort of tools would we use to exploit this platform? If you remember the Terminator movie I think when everyone gets sent back in time they show up naked so you can't really carry any sort of software tools on your person when you're going back in time. You know we kind of have to deal with what we have in that era obviously it was post-ENIAC era but some of the tools seemed like they were written for the ENIAC. Obviously if we're looking at debuggers we would like to launch up our Ida Pro as usual. That's not going to happen. Instead we're stuck with these two abominations a Portland Turbo Debugger which has it's like pseudo end curses interface as well as Softice which was a great program that these were really the only debuggers that were available for the Windows 3.x platform. So we're kind of hamstring by that or at least it makes it a little more complicated to look at some of these crashes that we'll get to.  They will barf on these files mostly because they're not PE files. The executables used on Windows 3.x are called NE which ironically was called new executable. It was new at the time but obviously it's not so new anymore. And this was the executable format for Windows 3.x. Sort of in between these stages here the MZ format was the DOS executable format invented by Mark Z from Microsoft. I don't know his last name. Zibikowski? Thank you. I'll drink for that. Every time you say Zibikowski I'll drink. It's turning into Summer Count again. So NE was sort of this evolution in the middle between MZ and PE. It had some backwards compatibility with MZ. If you see at the top there there's an old style file header which was the old MZ MS-DOS header which didn't allow it to inter-operate with backward compatibility but at least allowed it to output an error message so that when DOS tried to load an NE executable it would spit out an error message saying this requires a Windows environment to execute but if it was running in a Windows environment the Windows loader would know to look for the new header pointed to in that diagram there. And this was a pretty standard segmented executable layout where you have the bottom of the picture is cut off but you segment one then dot dot dot dot through segment N for your data encode and whatnot. So looking at what tools will you use for vulnerability discovery. We're going to be fuzzing our target which in this case is the paintbrush application. We would use any number of fuzzing frameworks out there like Soli or the BFF from cert or Peach, the popular Python fuzzing framework but since we can actually use these tools we can't bring it back in time with us we're going to have to stick with what we can do. So taking another note from Arnold's cinematic history in the movie Predator after he loses all his advanced weaponry he's forced to fight the Predator with sticks and stones where he coats himself with mud and starts making traps and spears out of sticks. So we have to do the same thing except that in our case the sticks are Fortran. So thank you, thank you. This is the first and last Fortran program I will ever write. I had no experience in Fortran before doing this and it was a horrible, horrible experience. This code looks like it's somewhat nice but it's really a nightmare. What this is is a simple byte mutation fuzzer. It takes an input file, randomly changes one byte of a random offset in the output file and obviously has some training harness to run and look for crashes. So in our case, since we were fuzzing the paintbrush application we took some couple standard bitmap files which is a pretty simple file format and started spitting them through this fuzz.f90 which I believe this is all valid f94 trans so it fits into our theme of 1994. I'm sure I could have done it in C but that wouldn't be as painful so it wouldn't have been as funny for you guys. So of course with any sort of fuzzing run the hardest thing is triaging all these samples. Normally you have tools like being exploitable from Microsoft or Crash Langer on OS X you have some sort of ability to automate this process somewhat. Unfortunately in this case you don't so I had to dive into my Windows 3.1 VM which amazingly still does run within VMware Workstation if you have it and manually triage through all these samples to look at what type of crashes they were if they were divided by zeros or general protection faults and try to triage these a little bit so that it wouldn't have to do so much effort but this borderland debugger is not the greatest tool on earth so it definitely was a painful process but there is obviously some evidence of memory corruption here and it turned out some of these fuzz samples were trivially exploitable they're simple you know stack buffer overruns which give us execution flow control some of the things you have to keep in mind though when you're actually exploiting Windows 16 as opposed to Windows 32 if you're doing the traditional popping your calc.exe and you want to use your crate process crate process doesn't actually exist in Windows 16 it was introduced in Windows 32 but we can use shell execute to pop the 16 bit calcs another sort of side effect of the Windows 16 memory architecture is that there's this lack of isolation between processes so if you hose one application your entire system goes down so actually going through these crashes was just absolutely ridiculously painful so we successfully eliminated the target by exploiting our MS Paint I think they might have been designing the movie in MS Paint or paintbrush I should say maybe it was like a flipbook style kind of like my presentation here so we've removed that from the past history and no one else will have that burned into their retinas anymore in the future thank you, thank you some other random bits I submitted some of these vulnerabilities to ZDI I wanted to cash in on these extremely high severity vulnerabilities that I think should go for at least 100k considering high value where they are and considering how often everyone runs a paintbrush on their Win 3.1 platform and not only did I want 100k but I also wanted the interest in inflation since 1994 because that obviously makes sense the vulnerabilities were discovered when I was back in time so that interest should be adding up and inflating my payout and the second question I have to ask for the developers at Microsoft, what were you thinking? why didn't you opt in to DEP? you should have known that DEP was going to be created a decade later and you definitely should have opt in permanent DEP set for a P brush and you would have been set, none of this would have been an issue and I don't know if you guys were at Black Hat but Microsoft actually released their I don't even know the stands for exploit mitigation something toolkit version 2 which sort of allows you to go back and change some of the DEP opt-in or other exploit mitigation mechanisms so if you guys download this make sure it works on all of your 16-bit binaries and if not, call Microsoft non-stop and complain about it because I want support to protect my paintbrush app so the only one serious slide I have in this entire presentation is about legacy systems and if you guys caught HD's presentation I think at B-Sides and potentially I think tomorrow the SkyTalks as well he was talking about VxWorks which is a very popular embedded platform and some of the vulnerabilities that are still around in that and that came out previously previous to Windows 3 3x as well I think VxWorks is from the mid-80s so you know these legacy systems tend to still be around VxWorks obviously has a more significant footprint than Windows 3.1 and has more implications in terms of the vulnerabilities that HD uncovered but the theme is sort of the same that these systems are still out there a lot of embedded systems actually do run Windows 3.1, a bunch also are Windows CE and so on and XP embedded but it turns out that Windows 3.1 was actually just recently end of life in November 2008 which I didn't know at the time but again when I was doing this presentation I came upon this and I thought that was really surprising that they were not only supporting this platform all the way through the end of 2008 but also still selling it so it indeed is very popular for these embedded platforms and it's not likely that any of these are going to be running Paintbrush or any of the other traditional applications that you would see on Windows 3.1 system but it's something to keep in mind when you're looking at legacy systems and sort of going back and saying hey what can we do with these systems before we even were talking about the X-Play techniques and the X-Play mitigations that we talk about today at Def Con and Black Hat. So with that I hope you guys had a good time I doubt you guys learned anything but if you do have any questions somehow besides how fast can you bong the beer I'll be happy to take them. Thank you guys. Steve Oren. I did look at some remote issues there were some remote crashes in the land manager service which is the same as WinPopup so with a simple one line SMB client command you could remotely crash the system but I don't think that is would be enabled on some of these Win3.1 embedded platforms as possible I don't know for sure but I suppose I can post details about that if people are actually interested it's only a DOS that I know of DOS on DOS, no pun intended. Steve Oren, any more questions? I would but I don't have my Win3.1 VM on this machine I'll post a video for you later though if you want you mean like fuzzing any format itself? I didn't do any of that. The fuzzer I wrote obviously was a dump fuzzer it was a format agnostic fuzzer I really didn't want to do anything more complex I thought about actually doing the actually BMP aware fuzzer in Fortram but I nixed that idea pretty quickly after I realized how painful it was just to write the initial fuzzer Alright guys, thanks a lot