full-disclosure - [sec-labs] Zone Alarm Device Driver vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20030805134455.4b82a0a0.noreply@sec-labs.hack.pl>
From: noreply at sec-labs.hack.pl (sec-labs team)
Subject: [sec-labs] Zone Alarm Device Driver vulnerability

     sec-labs team proudly presents:

     Local ZoneAlarm Firewall (probably all versions - tested on v3.1)
     Device Driver vulnerability.
     by Lord YuP
     04/08/2003

 I. BACKGROUND

   ZoneAlarm is a very powerful and very common nowadays firewall for
   Windows produced by Zone Labs. (http://www.zonelabs.com)

 II. DESCRIPTION

   The driver installed with ZoneAlarm is vulnerable, and can be
   exploited  in cause of that attacker can gain full system control
   (ring0 privileges).    

   By sending properly formatted message to the ZoneAlarm Device
   Driver (VSDATANT - TrueVector Device Driver) you can cause an
   device driver     memory overwrite. 

   Overview, sending faked buffors with specific singal can cause
   a miscellaneous code execution:

   First signal should be send to overwrite specific memory location,
   in the current case it can be one of the case-if-statement.

     push 0 					;overlapped
     push offset bytes_returned			;bytes returned
     push 4					;lpOutBuffer size
     push STATMENT_INSTRUCTION_POINTER		;memory to overwrite
     push 0					;lpInBuffer size
     push 0					;lpInBuffer
     push 8400000fh				;guess what X-D
     push vsdatant_handle			;device handle
     call DeviceIoControl			;send it!

   If the correct STATMENT_INSTRUCTION_POINTER will be put the address
   should be overwritten to 00060001h (example). After memory
   allocation     at this address (inserting shellcode bla bla bla), the
   second signal must     be send to jump into inserted code. That can
   be done with sending another     signal:

     LpInBuffer: 
     db STATMENT_OVERWRITTEN_NUMBER			;where to jump
     db 7 dup (0)					;data?
     dd temp_buff					;temp buffer
     db 10 dup (0)					;some space

   This one should be send with another dwIoControl code, however we
   are  no longer publishing any exploits, even PoC (die kiddies)

   After sending second faked message, device driver will jump 
   to the STATEMENT offset which was overwritten by first "signal"

 III. IMPACT

   The after sucessfull exploitation, attacker can obtain FULL SYSTEM
   CONTROL! In the worse for attacker option, OS can fault!

 IV. REFERENCE - DEVICE DRIVER ATTACKS

   The white paper about Device Drivers Attacks can be found at 
   http://sec-labs.hack.pl the papers section. 

-- 
sec-labs team [http://sec-labs.hack.pl]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030805/19c9b222/attachment.bin