[FWD] Vuln. in PG 2.000 & Vendor Response is "Fixing it with the next release" ?!

============================================================================
DiamondCS Process Guard Can Be Disabled by Direct Service Table Restoration
by Tan Chew Keong
Release Date: 07 July 2004
Summary

DiamondCS Process Guard is an advanced Win32 security system that protects both system and security processes (as well as user-defined processes) from attacks by other processes, services, drivers, and other forms of executing code on your system. The first program of its kind, Process Guard can protect a process against termination, suspension and prevents loading of malicious kernel drivers.

Process Guard protects a running process by hooking several native APIs in kernel-space. However, an implementation flaw allows a malicious program to disable Process Guard's protection by restoring the running kernel's SDT ServiceTable with direct writes to \device\physicalmemory.


Tested System

Process Guard Free v2.000 on Win2K SP2 and SP4.
Process Guard Free v2.000 on WinXP SP0 and SP1.


Details

Process Guard prevents a protected process from being terminated by hooking several native APIs in kernel-space. Hooking is performed by the module procguard.sys by replacing entries within the SDT ServiceTable. In addition, Process Guard prevents the installation of malicious kernel drivers by hooking ZwCreateKey and ZwSetValueKey. Hooking these two APIs prevents any programs from creating the necessary registry entries that are required to load a kernel driver or to install a service.

Using our KProcCheck rootkit-detection tool, we were able to determine that Process Guard hooks the following native APIs.

KProcCheck Version 0.1 Proof-of-Concept by SIG^2 (www.security.org.sg)

Checks SDT for Hooked Native APIs

ZwCreateFile 20 \??\C:\WINNT\System32\drivers\procguard.sys [F7392D8A]
ZwCreateKey 23 \??\C:\WINNT\System32\drivers\procguard.sys [F7391F98]
ZwCreateThread 2E \??\C:\WINNT\System32\drivers\procguard.sys [F73924FC]
ZwOpenFile 64 \??\C:\WINNT\System32\drivers\procguard.sys [F7392C62]
ZwOpenKey 67 \??\C:\WINNT\System32\drivers\procguard.sys [F7391F64]
ZwOpenProcess 6A \??\C:\WINNT\System32\drivers\procguard.sys [F739289E]
ZwOpenThread 6F \??\C:\WINNT\System32\drivers\procguard.sys [F73926F8]
ZwRequestWaitReplyPort B0 \??\C:\WINNT\System32\drivers\procguard.sys [F7390AE6]
ZwSetValueKey D7 \??\C:\WINNT\System32\drivers\procguard.sys [F739224E]
ZwWriteVirtualMemory F0 \??\C:\WINNT\System32\drivers\procguard.sys [F7392A40]

Number of Service Table entries hooked = 10


On Win2k/XP, it is possible to restore the running kernel's SDT ServiceTable to its original state since a complete copy of the SDT ServiceTable exists within the kernel file ntoskrnl.exe. Our SDTrestore rootkit-defense tool demonstrates how this could be done. Using our SDTrestore tool, we were able to restore the SDT ServiceTable of a system running Process Guard. The protection offered by Process Guard is effectively disabled after we restored the SDT to its original state. In other words, the processes that were being protected by Process Guard can now be easily killed using taskmgr.

Our SDTrestore tool is not blocked by Process Guard's driver-blocking feature since it writes directly to \device\physicalmemory and hence, do not need to load a kernel driver. The following screen dump shows SDTrestore in action.

C:\>sdtrestore
SDTrestore Version 0.1 Proof-of-Concept by SIG^2 G-TEC (www.security.org.sg)

KeServiceDescriptorTable 8046DFA0
KeServiceDecriptorTable.ServiceTable 804742B8
KeServiceDescriptorTable.ServiceLimit 248

ZwCreateFile 20 --[hooked by unknown at F7392D8A]--
ZwCreateKey 23 --[hooked by unknown at F7391F98]--
ZwCreateThread 2E --[hooked by unknown at F73924FC]--
ZwOpenFile 64 --[hooked by unknown at F7392C62]--
ZwOpenKey 67 --[hooked by unknown at F7391F64]--
ZwOpenProcess 6A --[hooked by unknown at F739289E]--
ZwOpenThread 6F --[hooked by unknown at F73926F8]--
ZwRequestWaitReplyPort B0 --[hooked by unknown at F7390AE6]--
ZwSetValueKey D7 --[hooked by unknown at F739224E]--
ZwWriteVirtualMemory F0 --[hooked by unknown at F7392A40]--

Number of Service Table entries hooked = 10

WARNING: THIS IS EXPERIMENTAL CODE. FIXING THE SDT MAY HAVE GRAVE
CONSEQUENCES, SUCH AS SYSTEM CRASH, DATA LOSS OR SYSTEM CORRUPTION.
PROCEED AT YOUR OWN RISK. YOU HAVE BEEN WARNED.

Fix SDT Entries (Y/N)? : y

[+] Patched SDT entry 20 to 80497EF9
[+] Patched SDT entry 23 to 804B2483
[+] Patched SDT entry 2E to 804A89AD
[+] Patched SDT entry 64 to 80498755
[+] Patched SDT entry 67 to 804B2E28
[+] Patched SDT entry 6A to 804A7D22
[+] Patched SDT entry 6F to 804BD7E4
[+] Patched SDT entry B0 to 8049D577
[+] Patched SDT entry D7 to 804B32F4
[+] Patched SDT entry F0 to 804A495B


Vendor Response

Vulnerability will be fixed in the next release.


Workarounds


Do not run untrusted programs as Administrator.

Disclosure Timeline

23 Jun 04 - Vulnerability Discovered
24 Jun 04 - Initial Vendor Notification
25 Jun 04 - Initial Vendor Response
07 Jul 04 - Public Release

 

Re: [FWD] Vulnerability in Proccess Guard 2.000 & Vendor Response is "Fixing it later" ?!

This has already been discussed, see here:
http://www.dslreports.com/forum/remark,10710029~mode=flat
And here https://www.wilderssecurity.com/showthread.php?t=40154

This is not a Process Guard vulnerability, but a trick that can be used to attack virtually any software (you could almost consider it a Windows vulnerability) - drivers can be bypassed by writing directly to kernel memory using a little-known trick that allows writing to \device\physicalmemory without requiring ring-0 access. The trick can also be used, for example, to bypass virtually any firewall, and virtually all other driver-based programs. As Phil Sloss (psloss - a Wilders forum member and programmer who is well-educated with kernel-mode tricks) wrote:

You can read more about this trick here.
(To my knowledge, no programs actually counter this trick - yet!).

We have already developed a countermeasure for this, and Process Guard will actually become the first program in the world to stop this. Not only that, it will also allow you to secure other programs against this attack, just as you can use Process Guard to stop virtually all other attacks against processes, but as I'm sure you can understand, this isn't an overnight process and will take some time.

However, there's not much to worry about between now and then, as you'll see when you read the thread in the aforementioned URL.

Best regards,
Wayne

 

check here:
https://www.wilderssecurity.com/showthread.php?t=40154

darn I was too slow...