Log in

View Full Version : # Process Explorer - bloody hell of indefinite waiting bugs


nezumi-lab
February 12th, 2009, 16:17
long time ago I found a bug in Process Explorer ("http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx") pointing out that it uses wrong algorithm of retrieving Thread Start Address. all threads created with CreateRemoteThread has Thread Start Address pointing to KERNEL32.DLL. it’s true, but help- and sense-less. I sent my bug report to Mark, but got no answer and posted it on my old blog: “bug in Process Explorer (a gift for malware) ("http://souriz.wordpress.com/2008/05/04/bug-in-process-explorer-gift-for-malware")”

it means that Process Explorer is not reliable enough, we can’t trust it anymore and yesterday I found more bugs. they’re very common and almost _every_ application has numerous bugs like this. are you intrigued? well, lets begin!!!

download ("http://nezumi-lab.org/ffh/to_attach_ldr.zip") to_attach_ldr.exe (anti-attach trick, based on damaged PEB=>PPEB_LDR_DATA - read this ("http://nezumi-lab.org/blog/?p=122") post for more info), run it and… ask Process Explorer to display properties of “to_attach_ldr.ex” process (yeah! “ex”, not “exe” - another bug?!). now, go to “Threads” tab and…

ops!!! Process Explorer freezes falling into infinitive loop with 100% CPU load. ~60% is to_attach_ldr.exe and ~40% is CSRSS.EXE. ok, close to_attach_ldr.exe and Process Explorer immediately wakes up. this means it just was waiting the even that was not going to happen.

ok, another example. download ("http://nezumi-lab.org/ffh/to_attach_33.zip") to_attach_33.exe (anti-attach based on intercepted NtRequestWaitReplyPort, described here ("http://nezumi-lab.org/blog/?p=139") ). run it and ask Process Explorer to show properties, go to “Threads” tab and… you know what will happens in the next moment. freezing!!!

http://nezumi-lab.org/gif/proc_exp_wait.giffreezing Process Explorer


we just found out how buggy Process Explorer is. but why? what’s the issue? the answer: NT has numerous functions like WaitForSingleObject, WaitForDebugEvent, etc. they all take dwMilliseconds argument specifies time to wait for an event. if the parameter is INFINITE, the function does not return until an event has occurred. the problem is - almost every programmer uses INFINITE and does not handles time out error. admit, you did this too?

Ilfak does for sure and I pointed out it before (”another EnableTracing() bug ("http://nezumi-lab.org/blog/?p=37")“.

ok, we got two points. first - never use INFINITE unless you’re 100% sure it works. the second point: if malware creates a malicious thread inside a trusted application - anti-attach tricks help it to survive. many anti-viruses are unable to enumerate threads in this case and some of them just freezes. very effective DoS attack against pro-active protections!!!

note: I tested Process Explorer 11.4 under W2K SP4, not tested other versions yet, but guess the bug is there.




http://nezumi-lab.org/blog/?p=141