Hi There.

I have recently discovered a new heap-based buffer overflow vulnerability in the microsoft windows platform. The only problem is that, as of yet, I have not been able to write an exploit for it, as I have never exploited a heap-based overflow before.

If you guys could help me out by answering a few questions I have (that will enable me to write the expoit), I will post the full-disclosure on governmentsecurity.org before posting it elsewhere. I will also be very happy to include the references to this site and to the names of everybody who contributes, in the full-disclosure post.

With regards to the vulnerability, it is not ideally suited to writing a virus (like the SqlSlammer vulnerability was), however it can be triggered remotely, and is present on a very large number of systems, so I expect it to get a lot of publicity.

The only reason I have not released a full-disclosure already, is that I would very much like to write the exploit code for it first.

------------------------------------------------------------------------------------------------------------------------------

OK I guess it might be helpful at this point if I included information about stuff I've done relating to the topic.

I have a fairly good understanding of:
- c
- asm
- stack-based overflows
- shellcode

I have written:
- exploit code for several windows stack-based overflows
- win32 shellcode template (encapsulates shellcode in order to provide portability and dynamic function resolution)

In attempt to increase my understanding of heap-based overflows I have read:
- w00w00 on heap overflows

--------------------------------------------------------------------------------------------------------------------------

With that out of the way, at the moment I only have one question (please keep in mind that as this is my first time with heap-based overflows, there may be a few more):


I have come to understand that when exploiting heap-based overflows, the goal is to overwrite a function pointer with the address of the shellcode. However I have absolutely no idea how to go about *locating* function pointers in memory that could potentially be overwritten.

--------------------------------------------------------------------------------------------------------------------------

Any help would be greatly appreciated.
Regards,
Suma

The Process Heap&Dynamic Heaps
Every process running on Win32 has a default heap known as the process heap.
Calling the C function GetProcessHeap() will return a handle to this
process heap.A pointer to the process heap is also stored in the Process Environment
Block(PEB).The pointer to following assembly code will return a pointer to the
process heap in the EAX register:
mov eax,dword ptr fs:[0x30]
mov eax,dword ptr[eax+0x18]
Many of the underlying functions of the Windows API that require a heap to
do their processing use this default process heap.
Further into default process heap,under Win32 ,a process can create as
many dynamic heaps as it sees fit.These dynamic heaps are available globally
within a process and are created with the HeapCreat() function.
ask me at no_face_king@yahoo.com (more help)

cool. do you use msn/yahoo messenger, or just over email?

1: Post the advisory (whenever you feel like too)
2: You can make the exploit, but if you are going to distribute it, you should wait a little so the hole can be patched on time, to prevent scriptkiddies.

ps: sqlslammer, you're talking about a mysql/sql hole ?

Uhh there are a few pointers u can overwrite. Traditional ones you overwrote the UEF (Universal Exception Filter) address. Some better methods have been found though, such as coalescing to make more universal heap overflows.

Either ask some questions here or read Shellcoders Handbook.

Paul:

Thanks for the advice... I will consider notifying microsoft before I release the advisory... that is, assuming that im able to exploit this hole. I've been spending a lot of time stepping through it in a debugger, and I have been getting more and more confused. Ollydbg is labelling it as a stack overflow, although I'm certain that this must be incorrect.

By my sqlslammer comment, I was trying to point out while *that* particular vulnerability was ideally suited to a virus, my vulnerability is *not*. My vulnerability can only be exploited by getting the user to open a specially crafted file. (Sorry for confusion here)

nolimit:

Nice. I will deffinately try to get a copy of Shellcoders Handbook. During my many google searches I have been unable to find much good information out there... maybe if i ever get a grip on heap overflows, I will write a tutorial.

I have a new question... will put it in seperate post.

OK here is the thing that is confusing the hell out of me atm:

I have determined that several different things happen, depending on how much I put into the buffer.


Full-fledged crash: I am assuming that the crash is caused by a excessive heap corruption.

Exits silently: This must be the range in which I have a chance gain control of the eip.


So according to this theory, if i were to fill the buffer up to just before the crash limit, with 'A' characters, this should result in *all* function pointers being overwritten. So how come, then, it just exits silently, and the eip dosn't get taken?

I have (ages ago) played around with a different heap overflow and I know that it dosn't work this way. However I'm trying to understand *why* this is so.


Sorry for my ignorance on the topic,
Cheers.
Suma

hey this sounds quite interesting ! but just a short question: why do you want to submit it to a forum when you can get a few thousand dollars for selling it to idefense or 3com...

just wondering

greetz,
Buzz

why do think dollors are goal?
have you ever seen one underground bo team?
just think about this site:www.pro.crouz.com/bof
hey man do you know how much unpublic exploit on there?
i was study shellcoders hnadbook more than 7 ...
books and tutorials aren't enough ...
and my friend forget eip on heap overflow new methods available

I'm currently reading an article i found on phrack called Advanced Doug Lea's Malloc Exploits. So far it seems to be a great article, and is answering a lot of my questions.

I should have known to go to phrack in the first place... I wish the old editors were continuing lol... 2007 is ages away.

It may take me a week or more to learn the techniques and get the exploit written... The school workload (I'm in yr12) is not helping, as I cant spend as much time as I'd like to be able to on this.

I will keep you guys up to date on progress.

-s

That assessment could be wrong. You really need to step through, and find out how the data is handled. You can do this by crashing it in a debugger, backstepping through the Call stack, and then breakpointing before the crash happens. Then send the overflow again and watch what happens, and how it happens.