('binary' encoding is not supported, stored as-is) In-Reply-To: <1048263395.5125.3.camel@Cadmium> I tried the sample DoS code, and it seems to do more than a DoS. I was able to crash applications beyond ActiveSync. This seems to me to indicate a write-overflow that *may* be exploitable to execute arbitrary code remotely. My system: Windows 2000, ActiveSync 3.1 (Build 9386) I have executed iPAQ_Crash 4 times, and each time I not only hung ActiveSync, but 3 out of 4 times I crashed another running application. 1st time: Running ReflectionX 8.0.5 with two xterms open. Started ActiveSync. Ran iPAQ_Crash. Result: 1. ActiveSync crashed. It remained "green and spinning" like it was trying to load data. 2. After a few seconds, "rx.exe" crashed (that's ReflectionX). 3. ActiveSync remailed hung until I killed WCESCOMM.EXE (ActiveSync). 2nd time: Restarted ReflectionX. Started ActiveSync. Ran iPAQ_Crash. Just ActiveSync hung. Nothing else died. 3rd time: Started Photoshop and Paint. Started ActiveSync. Started ReflectionX. Ran iPAQ_Crash. Photoshop crashed along with ActiveSync. 4th time: Close Paint. Left ReflectionX running. Started Photoshop and minesweeper (games). Started ActiveSync. Ran iPAQ_Crash. Minesweeper crashed along with ActiveSync. "Which" applications crashes is unknown, but the more things running, the more likely something else will crash. I suspect this has to do with a memory overflow. Knowing this, the overflow *may* be able to execute arbitrary code. (Unfortunately, I don't have a Windows debugger for validating this.) The original posting was for ActiveSync 3.5. I was using ActiveSync 3.1. Perhaps the write-overflow only happens with 3.1? Can someone else verify this? -Neal >ActiveSync version 3.5 Denial of Service Vulnerability [snip] >Description: >~~~~~~~~~~~~ > >By "pretending" to be an iPAQ and connecting to TCP port 5679, then sending= > a corrupted "I would like to sync with you" packet, a NULL pointer is dere= >ferenced in a call to the function WideCharToMultiByte() while it is trying= > to process an entry within the packet. This then causes an application err= >or, killing the "wcescomm" process. [snip]
This archive was generated by hypermail 2b30 : Tue Apr 01 2003 - 18:44:34 PST