ZoneAlarm Buffer Overflow in VSDATANT Device Driver Yields System Privileges to Local Users
SecurityTracker Alert ID: 1007420|
SecurityTracker URL: http://securitytracker.com/id/1007420
(Links to External Site)
Date: Aug 5 2003
Execution of arbitrary code via local system, Root access via local system|
Version(s): Tested on 3.1|
A buffer overflow vulnerability was reported in the ZoneAlarm firewall in the device driver. A local user can execute arbitrary code with full privileges.|
Lord YuP of sec-labs reported that a local user can send a specially crafted message to the VSDATANT TrueVector Device Driver to overwrite memory. A local user can reportedly gain ring0 privileges (full system control).
The local user can send one signal to overwrite a specific memory location (to contain the local user's arbitrary code) and then send second signal to cause the system to jump to the user-supplied arbitrary code.
Some exploit example details are provided in the Source Message.
Additional details about exploiting device driver flaws is available at:
A local user can execute arbitrary code with ring0 (system) privileges.|
No solution was available at the time of this entry.|
Vendor URL: www.zonelabs.com/ (Links to External Site)
Boundary error, Input validation error|
|Underlying OS: Windows (Any)|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Subject: [Full-Disclosure] [sec-labs] Zone Alarm Device Driver vulnerability|
Content-Type: text/plain; charset=US-ASCII
sec-labs team proudly presents:
Local ZoneAlarm Firewall (probably all versions - tested on v3.1)
Device Driver vulnerability.
by Lord YuP
ZoneAlarm is a very powerful and very common nowadays firewall for
Windows produced by Zone Labs. (http://www.zonelabs.com)
The driver installed with ZoneAlarm is vulnerable, and can be
exploited in cause of that attacker can gain full system control
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:
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"
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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
Full-Disclosure - We believe in it.