11

Being new to researching vulnerabilities in native applications (as opposed to web apps), I'm having difficulties understanding a crash in Debian's browser, Epiphany (version 2.30.6), and determining if it is exploitable.

I've discovered that the following HTML + CSS code causes a crash in Epiphany, when a redirect to another page happens:

<!DOCTYPE html>
<html>
<head>
<style type="text/css">
::-webkit-scrollbar-thumb {
   height:0;
}
::-webkit-scrollbar {
   overflow:visible;
}
</style>
<meta http-equiv="Refresh" content="1; http://www.example.com/" />
</head>
<body></body>
</html>

So far, I've been trying to learn about it and determine it's exploitability by using GDB and Valgrind.

GDB, most of the times, reports a Segmentation Fault or at an address which changes every time I run it. I've also seen it reporting SIGILL instead of SIGSEGV, but it's rare. Debugging further, I've discovered that this is being caused by a CALL [edx+0x228] instruction. The value of the edx register on the moment that this instruction is executed changes slightly on each execution, but, according to the memory map, it is always within the heap.

Valgrind reports a Invalid read of size 4, [...] 3 bytes after a block of size 61 free'd, just before a Jump to the invalid address stated on next line and, finally, the Segmentation Fault.

For me, it looks like an use-after-free bug. I'd like someone to confirm that I'm right.

Assuming that this is, in fact, an use-after-free, I know that the bug might be exploitable. However, I've never managed to overwrite the memory at the address which results from the expression edx+0x228, and therefore I cannot control the instruction pointer.

I believe that the reason for this is because the object is being freed just after the page redirect starts, thus I cannot overwrite the space in memory that it was occupying with Javascript that is executed when the page is loaded. I've tried adding a heap spray to window.onunload, however, adding this method (with any kind of code inside) actually prevents the crash from happening.

So, basically, my questions are:

  1. Is this really an use-after-free bug?
  2. If it is, how may I determine when the object is being freed, and therefore try to learn if it's possible to overwrite it's location in memory after it is freed?

Any suggestions about determining if code execution is possible with this bug, and how it would happen, is also welcome.

Thanks.

mds
  • 119
  • 4
  • 4
    Your Question was partially answered in http://security.stackexchange.com/questions/33604/why-is-application-crash-considered-insecure/33653#33653 – Ali Ahmad May 06 '13 at 11:07
  • Thanks, Ali Ahmad. I had already seen that diagram and the MSDN article. According to them, the invalid read is at a CALL instruction, and is therefore probably exploitable. My doubt about how to name this bug, and determine if the memory at the address in question can be overwritten, leading to code execution, remains, though. – mds May 06 '13 at 12:10
  • Is it just window.onunload that prevents the crash? Does it still crash if you add your heap spray to window.onload? I think you're on the right path. – petiepooo Jul 05 '13 at 15:04

1 Answers1

1

I'll assume that the question has two parts: "Is this exploitable? How can I confirm that this is is?"

It probably is. You're probably on the right path with the heap spray. Have you tried disabling ASLR? That will help clear things up.

Here is some feedback from another person:

This bug is not replicable in newer versions. But he could probably perform a heap spray. He is reporting that gdb is reporting a different address every time this is probably* due to ASLR he should turn that off and back on to make sure. He can step through the program by setting some very breakpoints with gdb and determining the context of the crash.

But idk why he isn't trying out the latest version instead of the oldstable release. But I have mad respect for his/her vigor.

Community
  • 1
daveloyall
  • 330
  • 2
  • 3
  • 13
  • 4
    @Simon, well, I edited the answer to reflect how I interpreted the question. If the question is only "is this exploitable?", then you are right: this doesn't answer doesn't cut it. But if the question also includes "how can I confirm that this is exploitable?", then I think that this answer is at least partially legitimate. Of course, we could go another route: the information about disabling ASLR could be added as a comment above, then this answer could be deleted since it's not complete enough. – daveloyall Jul 25 '13 at 16:30
  • 2
    I think this is the right path to confirming it. I'd much rather see contributions to the answer to improve it than to call it completely not an answer. – Jeff Ferland Jul 25 '13 at 18:25
  • This is just a question for my own information: OP says that he wants to write the the free'd memory location after it is free'd. Sounds good. But is it also possible to control what is written there in the first place? I mean if the data being free'd was some chunk of html, he could provide that, eh? This stuff is neat. :) – daveloyall Jul 25 '13 at 20:07