Re: IRM 004: ActiveSync Version 3.5 Denial of Service Vulnerability

[<panic () hackerfactor com>]

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]