I am a rookie hacker studying android vulnerabilities. My partner and I are studying "CVE-2010-1119". Unfortunately there does not appear to be enough information online. Could anyone please help me describe the principle of the vulnerability, ideally in a similar way to how this has been explained?
Asked
Active
Viewed 1,539 times
1 Answers
18
This is a very complex question, and I'm not sure where you stand technically. I'll lay out some background to help you get to the point.
Basic refresher
A computer has a couple of important parts: a Central Processing Unit (CPU) and Random Access Memory (RAM). Essentially, a CPU reads a few bytes of memory from RAM, performs the instruction they contain, modifies some data, reads a few more bytes, performs the next instruction, and so on. Most all modern computers work on this basic principle.
RAM is simply a chip with a lot of bytes of storage. The RAM chips in a typical PC might have 2 billion bytes (2GB). And each byte of that RAM has an "address", which is just a number that lets the CPU access that specific byte. The computer can store either data or program instructions in a byte, then come back later and read them. A computer can also store a value in one set of bytes that contains the address of a different set of bytes - this is called a pointer.
Of course, your desktop computer is a lot more complex than just one program. It loads many programs into different sections of RAM, and the CPU rapidly switches between all of them to do your tasks. One main program the computer runs is called the Operating System (OS) - Windows, iOS, Android, Linux. One job of the OS is to allow these programs to share the CPU without letting them crash into each other. The computer has only a limited amount of RAM that has to be shared by all the running programs. So instead of using any piece of RAM, each program must ask for RAM from the OS. The OS assigns an area of RAM for the program, and the program can do what it needs with it. But if it tries to access RAM that is not assigned to it, or tries to violate the privileges assigned to it, the OS will terminate the program.
But the OS handing out memory is kind of slow. Inside a program, a memory manager is responsible for the same task. When a program needs memory for a small task, like creating a window, the program's memory manager keeps track of RAM addresses that are assigned, and which are free. It keeps them in a table of pointers.
Object Oriented programming
Objects are a way for a programmer to logically group data and instructions for working with that data. Objects can represent anything the programmer needs, such as a Window or a Button or a Customer or a Link. A Window object might store an X and Y coordinate on the screen, maybe have some scroll bars, plus a "Draw()" method for painting the contents when the window becomes visible. A Button object might have an X and Y and height and width dimensions, text for a label, and a Draw() method for painting itself on a screen.
Within an object oriented program, a program will create and destroy thousands or even millions of objects continually while it runs. Creating an object uses a command called "new", which is simply asking for an area of RAM to be assigned to that object. The memory manager returns a pointer to the address of the RAM allocated to the object, and the program keeps this pointer associated with the object. When the program is done with the object, it calls "delete" to get rid of it. The memory manager then marks that RAM as freed-up, and will be able to assign that RAM to some other object request.
Some languages like Java and .Net run in a special runtime environment that automates the task of freeing memory after the objects are deleted. This automated task is called garbage collection. In other languages, like C and C++, the programmer is responsible for some memory management. And sometimes, the programmers make subtle mistakes.
The setup
When a program creates an object with new, the object name is associated with a pointer to the address in RAM assigned to contain the object's methods and data. The program can make a copy of that address, too, so that other objects can refer to that object. An example might be a Window object containing pointers to Button and Hyperlink objects. Perhaps the Button has a Hyperlink associated with it. So the Window may have a pointer to the Button, and the Button has a pointer to the Hyperlink. Meanwhile, the memory manager's table looks like this:
RAM Addresses:
1000-2000 assigned to MyWindow
2000-3000 assigned to MyButton
5000-8000 assigned to MyHyperlink
The code might look like this:
MyWindow::Draw()
{
...draws frame and scrollbars here...;
MyButton->Draw(); // Calls address 2000 to tell the button to draw itself.
}
MyButton::Draw()
{
...draws button and colors it in here...;
MyHyperlink->Draw(); // Calls address 5000 to tell the hyperlink to draw itself.
}
The bug
What if the Window object deletes the Hyperlink object, but doesn't tell the Button object? The Button still has a pointer to the Hyperlink's old memory address, but the memory manager has been told to delete the Hyperlink, and to free that memory up so it is available to some other object.
MyWindow::DeleteLinks()
{
delete MyHyperlink; // Frees the RAM from address 5000-8000.
Draw(); // Calls MyWindow::Draw to repaint the screen. Inside
// Draw, it uses MyButton's address of 2000 to tell
// the button to draw itself. And inside
// MyButton::Draw(), it will still call MyHyperlink->Draw()
// at address 5000, even though we just freed it!
}
Surprisingly, this usually works long enough to pass a test! When the memory manager is told to delete the MyHyperlink, it simply marks the space available, like this:
RAM Addresses:
1000-2000 assigned to MyWindow
2000-3000 assigned to MyButton
5000-8000 is free
But the bytes still hold their old values from when it was a Hyperlink. When MyButton->Draw() is called, the old MyHyperlink-Draw() function is still in RAM at address 5000. So the testers don't see any bugs, and the product goes to market. There is now a "use-after-free" vulnerability in this program.
The crash
Let's say there's a web page that makes the program create a button with a hyperlink, then destroys just the link, then creates a new Image object. The memory manager allocates the new Image in memory marked as free, which now includes the address space where the Hyperlink used to be. The Button's pointer to the Hyperlink is still pointing at 5000, which it thinks is still a valid Hyperlink. But when the Button uses the pointer to call the Hyperlink, it's instead incorrectly calling bytes stored in the RAM that used to be a hyperlink, but are now in the middle of image data.
RAM Addresses:
1000-2000 assigned to MyWindow
2000-3000 assigned to MyButton
3000-10000 assigned to MyImage, but MyButton still thinks that 5000 is MyHyperlink.
The program crashes, because address 5000 points squarely into the middle of a picture of puppies.
The exploit
A hacker notices this crash, and decides to exploit it. He places instructions in a specially built picture file so that when the picture is loaded, and MyButton->Draw() is called, it will execute the instructions contained at byte 2000 of his image. His image contains specially crafted code at 2000 (usually something like a NOP slide) that will divert the instruction pointer to his malware stored elsewhere in the picture that was downloaded. Once that code executes, he owns that computer.
The first thing a hacker generally tries to do once his code is executing is to exploit a second vulnerability in the operating system to try elevate its privileges. That way it can then download more sophisticated malware files, and write changes to files on the disk so that the next time the computer boots, it runs again. It could hide itself using a rootkit. It could run a bot client, or a keylogger. It could send spam. It could launch DDoS attacks. It could install Cryptolocker and blackmail the owner.
John Deters
- 33,650
- 3
- 57
- 110