5

Few days ago, FireEye has found a vulnerability, which affects all versions of IE (even the latest 11). Microsoft has official statement regarding this issue.

FireEye wrote a technical article on their blog which explains details:

The exploit leverages a previously unknown use-after-free vulnerability, and uses a well-known Flash exploitation technique to achieve arbitrary memory access and bypass Windows’ ASLR and DEP protections.

and exploitation. Although I think I understood the main point, I would be happy if someone would explain it in a simpler terms. I really enjoyed reading explanation about heartbleed vulnerability in openSsl, and hope that someone can explain it in a similar fashion.

2 Answers 2

1

I really have no idea what level of technical competency the asker or any/everyone here is coming from so let try to start from the very bottom and work up and do in the simplest language I can. Please don't be offended if you have a masters in computer science or you're some ROP legend or whatever...

In order to understand the exploit in question, even at a basic level, you need to have some understanding of how a computer computes, ie you need to understand the fundamentals of a 'stored program controlled' machine. Once you have some grasp of that, we can talk about general buffer overflow attacks. Then once we understand buffer overflows we have an understanding of both of those things can we start to look at specific examples, non the less, relatively advanced examples making use of several of these more advanced techniques and hope to actually understand them in any detail.

Starting at the very bottom, let's briefly talk about how a computer computes or how processor processes... In your computer you have a CPU and the CPU has various registers on which it can do direct mathematical operations. The computer also has memory, where programs are loaded and run from. There's a special register called the instruction pointer and it's job is to point to location in memory where the current running program's instruction is located so the CPU can fetch and execute it. It does this one by one executing instructions until it gets to a jump or branch or return, etc. Then it will change the instruction pointer so it points to different place in memory and continues execution. This instruction pointer is very important. If you can hijack it, you might be able to get the computer to run things you put in other places in memory. Ever seen those t shirts which say “Got EIP?” That's what we're talking about here. If you can control EIP, you can control the machine.

Now, let's move 'up' a bit from this 'machine level.' Most modern programing languages have this concept of a subroutine call. This will cause the instruction pointer to jump to new area of memory where the function 's code is located. The function will run until it's finished and then control will return to the main program causing the instruction pointer to be set back to the place in the main function where execution left off before. To simplify that a bit.. So you've got this program running, and it runs until it gets to a function call. The function call will move execution to a different place in memory. It will then run in the new place until it gets to a return. At which point it will have to return to the main function. It should be clear that the machine is going to have remember that initial value, the value of the initial instruction pointer otherwise it wont know here to return to. This is known a return pointer. So the return pointer contains the address of the calling function and is stored in a data structure (in memory) called the stack. The stack works in a LIFO manner, last in first out, hence why it's referred to as a 'stack.' The last one in is the first one out. Generally the stack contains things associated with function calls. Think of the stack as a sort of post it note for little things to remember. So when a function call gets made, the first thing that gets pushed on the stack is the function call arguments.. if there are any.. it then pushes the value of the instruction pointer in the main program on the stack (the return pointer). then the function itself is invoked and it allocates space on the stack for local variables of the function itself. The function does it it's thing until it gets to its return. At which point those local variables come (pop) off the stack, then the return pointer is popped off and which, once again, gets set as the instruction pointer - and we return to execution in the main program. This is literally happening millions of time per second on the computer in front of you.

Now, lets get into buffer overflow bugs. Buffer overflows in a class of bugs known as code errors. Buffer overflows have been known about many decades, but didn't became mainstream until back in 1996 with Aleph One's seminal paper called “Smashing the Stack for Fun and Profit” which appeared in Phrack magazine issue 49. It's a worthwhile read, even today. Buffer overflows allow an attacker to send data to a target machine and get some code executed ie, getting root/admin on the box. Some work locally and other work across the network. The basic idea is that a program which accepts user input, but doesn't properly check the size of the data before moving it around. It's about not having proper bounds checking on the input field. Think of shoving something very large into a small box. I won't get into an actual example of some vulnerable C code for the sake of both simplicity and brevity, the later of which is probably already out the window.

CHECK BACK IN A FEW HOURS. I have to go right now. I will be back. I will talk about the specific exploit in question. Sorry if this non-typical or usual behavior for this site, I am new here. Only been on a handful of times.

0

I will try to be simple. Browser exploits are client side vulnerabilities that can be used to bypass the sandbox environment of the browser as well as the OS to gain escalated privilege on the machine.

Use after free vulnerability: UAF is a typical browser vulnerability that appears frequently in almost all the popular browsers. In this vulnerability, the attacker first creates a Javascript object, and then deletes it. Once the object is deleted or freed, the script tries to again access the same object. This leads to a memory corruption inside the browser. Now, in order to locate accurately the memory locations to control the pointers, the attacker uses memory spraying techniques like Heap spray or Return Oriented Programming (ROP). Based on the type of operating system, the attacker applies different techniques to spray the memory with junk data and launch the payload after successful exploitation.

I tried to be simple. Hope it helps you.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .