This week is a very busy week! After the OWASP & Beltug meetings, I attended the ISSA Brussels Chapter Meeting tonight. Two excellent speakers (and friends) were invited to talk about their favorite topics. Peter from the Corelan Team talked about “Memory Corruption in the Win32 world” (or “2012.eip=0x41414141“). Didier presented “Let’s Go Play In The Sandbox“. Relaxed atmosphere, lot of people present and pretty the same faces as during the OWASP meeting. The Belgium security landscape is definitively as small as the country!
Peter talked first and started with some history and facts. By memory corruption, vulnerability researchers try to execute arbitrary code in a system. Their well-known proof of concept is to pop-up a calculator (“calc.exe”). I’m always scared when I see one on my screen. First question from Peter: Why focus on 32bits systems while modern computers are able to execute 64bits code? Simply because most of them still runs 32bits versions of the operating system and applications. Do you know that the default browser in Windows 7 remains the 32bits version of Internet Explorer? Peter explained very clearly the basis of how memory management works under Windows (stack, heap, code, …). The goal of the attacker is to take control of the EIP (“Extended Instruction Pointer“) and to make it point to the next instruction to execute (a specific address where the payload has been loaded). If we overwrite the stack, at least the system will become unstable but, properly done, we can successfully overwrite the EIP and make the system act differently.
The next question was: “Can we avoid memory corruptions?“. Again, humans are the problem. They cause input validation problems, logic errors, signedness issues. But, as said Peter, computers may also introduce problems (compiler might introduce vulnerabilities even if the code is clean). And those problems are not new: The first buffer overflow was written in 1988 (the Morris worm). Around 2007, there was a peak of such attacks against Windows systems and, today, browsers are the main targets! Then, Peter gave some examples of exploitation methods:
- Saved return pointer overwrite
- Exception handlers (used by Code Red in 2001)
- Heap spraying: technique to deliver a payload
I noted Peter’s quote: “Exploit development is very easy!“. And today, what are the mechanisms available to protect us against such attacks? Memory protection was introduced with Windows XP SP2. They are:
- Canary/ stack cookie
- Safeseh
- Sehop
- ASLR
- DEP
- Heap spray mitigation
So problems are solved? Are we now safe in 2012? According to Peter, great enhancements have been introduced in modern operating systems and applications: Windows 2008R2 enables ASLR, DEP, Sehop by default. The worse is Windows XP SP3 which is still heavily used! Some features aren’t enabled by default just to ensure the compatibility with old applications. What about the Microsoft sotwares? For Peter, Microsoft is doing a good job. Latest versions have those features enabled by default or are compiled/linked with the right options. The same applies for the development suites (Good Peter’s remark: This does not mean you have to write sloppy code!). Most big vendors follow the same way and are distributing their applications with protections enabled. But some applications remain vulnerable. Bad example: Wireshark which had a problem while processing DECT packets. Finally, Peter made a live demo of its tool called Mona. He also mentioned the Microsoft tool EMET. Great talk explaining complex mechanism with simple words!
After a small break, Didier presented his research about “sanboxes“. This protection mechanism is not recent, he already mentioned this principle in a presentation in 2008. The goal of a sandbox is not to prevent the payload to be executed but it is executed in a safe container without communication with the outside world. They are different types of sandboxes: kernel-mode and user-mode. Didier’s presentation focused on the second type. The advantages of user-mode sandboxes? They do not require administrator rights and no specific software/drivers. Even portable applications can be executed in such environments. For Didier, if an application implements a sandbox system, this is clearly a sign of maturity. The first mention of a sandbox was made during BlackHat 2007 by David Leblanc. The first tool was called MOICE (“Microsoft Office Isolated Conversion Environment“). By default, processes belonging to the same users can talk to each others without any restriction. The idea was to run applications in an isolated processed with restrictions like no access to the registry or no write access to the file system. In Windows 2000, this was implemented via Job Objects. The idea looks like the jobs are implemented in mainframe environments: processes belongs to a job and this job has limitations (ex: maximum 10 process or 20% of the CPU). The basic sandbox was to create a job with only one process allowed: This prevented the exploit to run. The next element required by a sandbox is a security token. It describes what a process can do (who and which privileges). Sandboxes run with restricted security tokens. Then, Windows Vista introduced the integrity levels. Each process has a level (low, medium or high) based on MAC (“Mandatory Access Control“). A process with a medium level will be able to communicate with a low level process but never with a higher level one. Finally the Desktop (not the one you use as environment) is a kernel object to which applications are attached to. To resume, a sandbox is based on the following elements:
- A job object
- A security token
- An integrity level
- A desktop
Based on this, the problem is to interact with the user: He works in a desktop and his process runs in another desktop without any interaction between them. This interaction is performed via a “Broker” which exchanges information with the sandbox. This broker will make security decisions and communicates with the sandbox via IPC like named pipes. Didier insisted on the fact that this communication must be as simple as possible to avoid bug. Otherwise the problems will be transposed to the Broker and the sandbox will become useless.
Then Didier reviewed the status of big softwares:
- Internet Explorer : Sandbox implemented since version 7. Microsoft called it “Protected Mode“. It does not use a desktop. This means that only classic malwares are blocked but it’s still possible to steal data and extrude them!
- Chrome : It’s the best implementation of a sandbox system. The four elements are implemented
- Microsoft Office : It’s called “Protected View” and is used only to view files downloaded from the Internet.
- Adobe Reader : It’s called “Protected Mode” and based on the Chrome sandbox. It’s available only from version 10. All PDF’s are open in the sandbox.
What about Firefox? They don’t have plan to implement a sandbox. Note that Windows does not have any mechanism to implement access controls on network sockets. According to Didier, the main reason why sandboxes are not implemented in all application: it’s challenging to add them to an exiting application. Best is to implement them from the beginning (like Chrome). Finally, how to implement a sandbox in your own applications? This could require a lot of efforts. The best is to have a look at Google Chromium which is open source. There is a sub-project called sandbox_poc which implement a sandbox. Didier ended with a small demo of ProcessExplorer to show the effect of a sandbox on processes.
Great presentations! Two next events are already scheduled: 29/03 (mobile devices security) and 03/05 (privacy legislation).