感谢AYANAMI REI的翻译。Core Security Technologies - CoreLabs Advisory
http://www.coresecurity.com/corelabs/
对多款杀毒软件和防火墙的SSDT Hook函数的参数验证不严
*报告信息*
标题:对多款杀毒软件和防火墙的SSDT Hook函数的参数验证不严
报告ID: CORE-2008-0320
报告URL:http://www.coresecurity.com/?action=item&id=2249
发布日期: 2008-04-28
最后更新日期: 2008-04-28
包含厂商: BitDefender, Comodo, Sophos和瑞星
发布模式: 协调发布(BitDefender, Comodo, Rising), 用户发布 (Sophos)
*漏洞信息*
类别：无效内存参数
可远程利用：否
可本地利用：是
Bugtraq ID：28741，28742，28743，28744
CVE 名称：CVE-2008-1735, CVE-2008-1736, CVE-2008-1737, CVE-2008 -1738
*漏洞描述*
通过对多款杀毒软件和防火墙的（BitDefender Antivirus [1], Comodo Firewall [2],
Sophos Antivirus [3]和瑞星杀毒软件[4]）的SSDT hook
函数的粗略检查发现可以导致拒绝服务（DOS），并可能执行代码攻击。 攻击者利用这些缺陷可以本地重启系统，关闭防火墙和杀毒软件保护。然
而，很多情况下它可能利用这些bug导致在特权内核模式下执行任意代码 。
‘
*漏洞影响版本*
. BitDefender Antivirus 2008 Build 11.0.11
. Comodo Firewall Pro 2.4.18.184
. Sophos Antivirus 7.0.5
. 瑞星杀毒软件19.60.0.0 and 19.66.0.0
. 旧版本未测试，可能会被影响.
*不受影响的版本*
. BitDefender Antivirus 2008版本可以通过自动更新更新至一月18号之 后的版本
. Comodo Firewall Pro 3.0
. 瑞星杀毒软件20.38.20
*厂商信息，解决方案和其他*
1) BITDEFENDER ANTIVIRUS (BID 28741, CVE-2008-1735)
根据BitDefender的说明，这个缺陷尚未被恶意程序利用，并且可通过自 动更新修正。这一问题的信息可以在BitDefender的网站上找到：http://kb.bitdefender.com/KB419-en–Security-vulnerability-in- BitDefender-2008.html
2) COMODO FIREWALL PRO (BID 28742, CVE-2008-1736)
这个漏洞在Comodo Firewall Pro 3.0中被修正，新版本在http://www.personalfirewall.comodo.com/download_firewall.html下 载
3) SOPHOS ANTIVIRUS (BID 28743, CVE-2008-1737)
厂商声明：“在windows 2000，2003和XP下的Sophos Anti-Virus 7.x将 会受此漏洞影响。”不受影响的SOPHOS产品包括早起的SOPHOS windows杀 毒软件，SOPHOS飞windows平台杀毒软件和其他SOPHOS产品。
这个漏洞只有在实时行为分析开启状态才可以利用。它需要用户将web浏 览器的安全设置调整到默认级别以下或者允许从网页上启动ActiveX或 Java Applet。
可以使用以下方法避免漏洞被利用：
a. 使用默认的安全设置或较高级别的最新版本Web浏览器。作为通用的安 全管理，我们不建议用户下载ActiveX或者Java Applets，除非你信任他 的内容。
b. 关闭Sophos Anti-Virus的实时行为分析功能。（用户仍会受到Sophos 行为遗传分析和其他方式的对抗恶意软件的保护手段的保护。）
N.B. 如果攻击程序被放出，Sophos将会部署保护以对抗攻击程序。
漏洞的修复需要用户重新启动终端。鉴于为非紧急漏洞，为了尽量不打扰 我们的客户，Sophos将会尽早的在一个需要重新启动的产品中包含这个修 正。
4) RISING ANTIVIRUS (BID 28744, CVE-2008-1738)
瑞星杀毒软件的修正版可以在http://rsdownload.rising.com.cn/for_down/rsfree/ravolusrfree.exe下载。
所有的瑞星用户都可以通过自动更新更新到修补过的版本。
*荣誉归功于*
这些漏洞（除了瑞星）是被Core Security Technologies的Damian Saura, Anibal Sacco,
Dario Menichelli, Norberto Kueffner, Andres Blancoy Rodrigo
Carvalho在bugweek 2007时发现的。瑞星漏洞是被Core
Security Technologies exploit writers team的Anibal Sacco发现的。
*技术描述/poc代码*
我们发现BitDefender Antivirus, 瑞星杀毒软件, Comodo
Firewall和Sophos Antivirus并没有在使用hook函数时验证参数，导致程序试图转向无效内存，导致BSOD（Blue Screen of Death）。
在我们的测试中，我们使用了内核hook探测工具BSODhook [5]去寻找任何形式的未被充分验证的SSDT hook参数。从Matousec的文件[6]：
“Hooking kernel functions by modifying the System Service Descriptor
Table (SSDT) is a very popular method of implementation of additional
security features and is used frequently by personal firewalls and other
security and low-level software. Although undocumented and despised by
Microsoft, this technique can be implemented in a correct and stable
way. However, many software vendors do not follow the rules and
recommendations for kernel-mode code writing and many drivers that
implement SSDT hooking do not properly validate the parameters of the
hooking functions.”
“Hooking SSDT functions requires extra caution. SSDT function handlers
are executed in the kernel mode but their callers are executed in the
user mode. Hence all function arguments come from the user mode. This is
why it is necessary to validate these arguments properly. Otherwise a
simple user call can easily crash the whole system. This bug usually
results in a system crash. However, it may happen that this bug is even
more dangerous and may lead to the execution of an arbitrary code in the
privileged kernel mode.”
A local DoS attack, despite not being a very sophisticated intrusion
attack, could be used as an accessory under several scenarios. It is
commonly used by viruses as added feature, when the specific AV is
detected on the infected machine, crashing the system just to annoy. Or
by a human attacker, after a succesful remote intrusion with
unprivileged credentials to make a computer resource unavailable to its
intended users. Besides, this could be a very valuable resource when
trying to fake some service that answers broadcasts request like a DHCP,
allowing to start the service in another location replacing the original
one.
1) BITDEFENDER ANTIVIRUS (BID 28741, CVE-2008-1735)
BitDefender fails to validate the pointer to the ‘CLIENT_ID’ structure
provided to ‘NtOpenProcess’. So, if we pass an invalid pointer, we will
crash the whole system.
/———–
NtOpenProcess(PHANDLE ProcessHandle,
ACCESS_MASK AccessMask,
POBJECT_ATTRIBUTES ObjectAttributes,
PCLIENT_ID ClientId )
.text:00010ADE push 0Ch
.text:00010AE0 push offset stru_114E8
.text:00010AE5 call __SEH_prolog
.text:00010AEA call KeGetCurrentThread
.text:00010AEF xor ebx, ebx
.text:00010AF1 cmp [eax+140h], bl
.text:00010AF7 jz short loc_10B0D
.text:00010AF9 call PsGetCurrentProcessId
.text:00010AFE call PsGetCurrentProcessId
.text:00010B03 push eax
.text:00010B04 call sub_10724
.text:00010B09 test eax, eax
.text:00010B0B jnz short loc_10B12
.text:00010B0D
.text:00010B0D loc_10B0D: ; CODE XREF: sub_10ADE+19_j
.text:00010B0D push [ebp+ClientId]
.text:00010B10 jmp short loc_10B73
.text:00010B12
.text:00010B12 loc_10B12: ; CODE XREF: sub_10ADE+2D_j
.text:00010B12 mov edi, [ebp+ClientId]
.text:00010B15 cmp edi, ebx ; Little check to avoid a
Null Pointer
- ———–/
Here it gets the pointer to the ‘ClientId’ value, and if it is non zero
(’!= 0′) it does not care where it is pointing to.
/———–
.text:00010B17 jnz short loc_10B1C
.text:00010B19 push ebx
.text:00010B1A jmp short loc_10B73
.text:00010B1C
.text:00010B1C loc_10B1C: ; CODE XREF: sub_10ADE+39_j
.text:00010B1C mov [ebp+ms_exc.disabled], ebx
.text:00010B1F mov esi, [edi] ; Here it crashes
- ———–/
It access to that memory, and if that is invalid memory the system will
crash.
/———–
.text:00010B21 mov [ebp+var_1C], esi
.text:00010B24 or [ebp+ms_exc.disabled], 0FFFFFFFFh
.text:00010B28 jmp short loc_10B3B
.text:00010B28 sub_10ADE endp
- ———–/
2) COMODO FIREWALL PRO (BID 28742, CVE-2008-1736)
In Comodo there are problems in the arguments validation of
‘NtDeleteFile’, ‘NtCreateFile’ and ‘NtSetThreadContext’ functions.
‘NtDeleteFile’ receives just one parameter, a pointer to an
‘OBJECT_ATTRIBUTES’ structure. These attributes would include the
‘ObjectName’ and the ‘SECURITY_DESCRIPTOR’, for example. This is the
hook placed by Comodo at ‘NtDeleteFile’.
/———–
NTDeleteFile (POBJECT_ATTRIBUTES ObjectAttributes)
.text:0001ACB0 push 1Ch
.text:0001ACB2 push offset stru_1E3F0
.text:0001ACB7 call __SEH_prolog
.text:0001ACBC xor ebx, ebx
.text:0001ACBE inc ebx
.text:0001ACBF mov [ebp+var_1C], ebx
.text:0001ACC2 xor esi, esi
.text:0001ACC4 mov [ebp+var_24], esi
.text:0001ACC7 mov [ebp+var_20], ebx
.text:0001ACCA mov [ebp+var_28], esi
.text:0001ACCD mov [ebp+ms_exc.disabled], esi
.text:0001ACD0 call ds:ExGetPreviousMode
.text:0001ACD6 mov edi, [ebp+ObjectAttributes]
- ———–/
Here it does a lot of ‘ProbeForRead’ checks to see if the pointers of
the structure are valid. Nice! (’EDI’ still has a pointer to the
‘OBJECT_ATTRIBUTES’ structure)
/———–
….
.text:0001AD25 push edi ; ObjectAttributes
.text:0001AD26 call sub_1A692 ; Here it passes the
OBJECT_ATTRIBUTES structure pointer to the next function.
sub_1A692
.text:0001A692 push 28h
.text:0001A694 push offset stru_1E3C0
.text:0001A699 call __SEH_prolog
.text:0001A69E xor edi, edi
….
.text:0001A6B3 mov [ebp+ms_exc.disabled], edi
.text:0001A6B6 push 72747052h ; Tag
.text:0001A6BB mov ebx, 400h
.text:0001A6C0 push ebx ; NumberOfBytes
.text:0001A6C1 push 1 ; PoolType
.text:0001A6C3 call ds:ExAllocatePoolWithTag ; Allocates memory to
hold the data retrieved by ZwQueryObject
.text:0001A6C9 mov esi, eax
.text:0001A6CB mov [ebp+var_28], esi
.text:0001A6CE cmp esi, edi
.text:0001A6D0 jz short loc_1A74F
.text:0001A6D2 mov edi, [ebp+ObjectAttributes]
.text:0001A6D5 mov eax, [edi+OBJECT_ATTRIBUTES.RootDirectory] ;
Here, the code retrieves the RootDirectory’s field value from the
structure, controled by us.
.text:0001A6D8 test eax, eax
.text:0001A6DA jz short loc_1A71B
.text:0001A6DC push 0 ; ReturnLength
.text:0001A6DE push ebx ; ObjectInformationLength
.text:0001A6DF push esi ; ObjectInformation
; buffer where ZwQueryObject will put the object information
.text:0001A6E0 push 1 ; ObjectInformationClass
; Specifies an OBJECT_INFORMATION_CLASS value that determines the type
; of information returned in the ObjectInformation buffer. It’s using
; an undocumented type (OBJECT_NAME_INFORMATION) which returns an
UNICODE_STRING structure
.text:0001A6E2 push eax ; ObjectHandle
; Now, the user-controlled handle ‘ll be used here to identify the
object by ZwQueryObject,
.text:0001A6E3 call ds:ZwQueryObject
.text:0001A6E9 mov [ebp+var_20], eax
.text:0001A6EC test eax, eax
.text:0001A6EE jl short loc_1A746
- ———–/
Here is where the problem shows up. The code does not properly validates
the data retrieved by ‘ZwQueryObject’, expecting an ‘UNICODE_STRING’
structure. But it is possible to make multiple calls to the function
using different handlers to obtain a null structure crashing the system
when the code tries to dereference its ‘Buffer’ field.
/———–
.text:0001A6F0 movzx eax, [esi+UNICODE_STRING.Length]
.text:0001A6F3 shr eax, 1
.text:0001A6F5 mov ecx, [esi+UNICODE_STRING.Buffer]
.text:0001A6F8 movzx eax, word ptr [ecx+eax*2-2] ; Here is the problem
.text:0001A6FD mov [ebp+var_30], eax
.text:0001A700 cmp ax, 5Ch
.text:0001A704 jz short loc_1A725
- ———–/
3) SOPHOS ANTIVIRUS (BID 28743, CVE-2008-1737)
Insufficient argument validation of hooked SSDT functions on Sophos lead
to a DoS. An attacker, utilizing this flaw, would be able to locally
reboot the whole system shutting down the Firewall or AV protection.
Although neither the vendor nor Core Security has found a means of
exploiting the flaw to execute arbitrary code, it has not been possible
to rule this out.
In Sophos AV there is a problem in the arguments validation of
‘NtCreateKey’ function.
/———–
int __cdecl NtCreateKeyHook(PHANDLE pKeyHandle,
ACCESS_MASK DesiredAccess,
POBJECT_ATTRIBUTES ObjectAttributes,
ULONG TitleIndex,PUNICODE_STRING Class,
ULONG CreateOptions,
PULONG Disposition)
[…]
.text:0001C01C push 4 ; Alignment
.text:0001C01E push 18h ; Length
.text:0001C020 mov esi, [ebp+ObjectAttributes]
.text:0001C023 push esi ; Address
.text:0001C024 call ds:ProbeForRead
- ———–/
Here it checks for ‘ObjectAttributes’ to be pointing to a valid address.
/———–
.text:0001C02A mov eax, [esi+OBJECT_ATTRIBUTES.RootDirectory]
.text:0001C02D mov [ebp+Handle], eax
.text:0001C030 mov esi, [esi+OBJECT_ATTRIBUTES.ObjectName]
.text:0001C033 mov [ebp+pUnicodeString], esi
- ———–/
Now, it gets from ‘OBJECT_ATTRIBUTES’ a handle and a pointer to an
‘UNICODE_STRING’ structure.
/———–
.text:0001C095 push 4
.text:0001C097 push 8
.text:0001C099 push esi
.text:0001C09A mov ebx, ds:ProbeForRead
.text:0001C0A0 call ebx ; ProbeForRead, it checks the
pointer before the dereference.
.text:0001C0A2 mov eax, dword ptr [esi+UNICODE_STRING.Length]
.text:0001C0A4 mov dword ptr [ebp+stUnicodeString.Length], eax
.text:0001C0A7 mov esi, [esi+UNICODE_STRING.Buffer] ; And gets
from the UNICODE_STRING structure
; a pointer to the unicode buffer.
.text:0001C0AA mov [ebp+stUnicodeString.Buffer], esi
.text:0001C0AD push 2 ; Alignment
.text:0001C0AF shr eax, 10h
.text:0001C0B2 push eax ; Length
.text:0001C0B3 push esi ; Address
.text:0001C0B4 call ebx ; ProbeForRead
- ———–/
It does the check, but here is the problem
/———–
.text:0001C0B6 push gdwValue
.text:0001C0BC lea eax, [ebp+stUnicodeString]
.text:0001C0BF push eax
.text:0001C0C0 push [ebp+Object]
.text:0001C0C3 call sub_1cb40
- ———–/
The problem relies in the function not properly checking the ‘Length’
field of the ‘UNICODE_STRING’ structure. When doing the check,
‘ProbeForRead’ receives the length field of the structure as a parameter
without any kind of validation.
So, if we set this field to 0, ‘ProbeForRead’ will not raise any
exception even though we were passing it an invalid address. And it will
crash when trying to access to the desired invalid memory.
/———–
sub_1cb40
[…]
.text:0001CB5E xor esi, esi
.text:0001CB60 mov [ebp+ms_exc.disabled], esi
.text:0001CB63 mov edi, [ebp+pUnicodeString]
.text:0001CB66 mov eax, [edi+UNICODE_STRING.Buffer]
- ———–/
And here is where it will crash:
/———–
.text:0001CB69 cmp word ptr [eax], ‘\’ ; Reference the first
pointed byte
- ———–/
4) RISING ANTIVIRUS (BID 28744, CVE-2008-1738)
In Rising antivirus the code of the ‘NtOpenProcess’ hook does not
validates if the pointer to the structure
/———–
typedef struct _CLIENT_ID {
HANDLE UniqueProcess;
HANDLE UniqueThread;}
- ———–/
is really pointing to mapped memory. So, when the code tries to
dereference the pointer to check the ‘CLIENT_ID->UniqueProcess’ value,
if it is pointing to invalid memory, will crash.
/———–
NtOpenProcess( OUT PHANDLE ProcessHandle,
IN ACCESS_MASK AccessMask,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN PCLIENT_ID ClientId )
.text:00010EAA push ebp
.text:00010EAB mov ebp, esp
.text:00010EAD push esi
.text:00010EAE mov esi, offset Addend
.text:00010EB3 push edi
.text:00010EB4 mov ecx, esi ; Addend
.text:00010EB6 call ds:InterlockedIncrement
.text:00010EBC call PsGetCurrentProcessId
.text:00010EC1 cmp eax, dword_11C8C
.text:00010EC7 jnz short loc_10ECE
.text:00010EC9
.text:00010EC9 loc_10EC9: ; CODE XREF: sub_10EAA+37_j
.text:00010EC9 push [ebp+ClientId]
.text:00010ECC jmp short loc_10EF0
.text:00010ECE
.text:00010ECE loc_10ECE: ; CODE XREF: sub_10EAA+1D_j
.text:00010ECE call PsGetCurrentProcessId
.text:00010ED3 mov ecx, dword_11C80
.text:00010ED9 push eax
.text:00010EDA call sub_11070
.text:00010EDF test al, al
.text:00010EE1 jnz short loc_10EC9
.text:00010EE3 call PsGetCurrentProcessId
.text:00010EE8 mov edi, [ebp+ClientId] ; Here is the bug, if
ClientId is pointing to an invalid address
.text:00010EEB cmp eax, [edi] ; it will crash.
.text:00010EED jnz short loc_10F0D
- ———–/
*Report Timeline*
. 2008-01-11: Core Security Technologies found a security vulnerability
in BitDefender antivirus.
. 2008-01-14: BitDefender team is contacted by Core.
. 2008-01-15: BitDefender team asks Core for technical description of
the vulnerability.
. 2008-01-15: Technical details are sent to BitDefender team by Core.
. 2008-01-22: BitDefender notifies Core that a fix has been produced and
the flaw was corrected through automatic updates.
. 2008-02-04: According to the original schedule, the CORE-2008-0320
advisory would be released at this date, but similar flaws in other
antivirus products were discovered by Core exploit writers team.
Considering all BitDefender users are patched, Core Security
Technologies does not release the advisory and continues the research of
this issue in other products.
. 2008-03-20: Core analyzes similar vulnerabilities in Comodo Firewall,
Sophos Antivirus and Rising Antivirus.
. 2008-03-25: Core notifies the Comodo, Sophos and Rising teams of the
vulnerabilities.
. 2008-03-27: Comodo team asks Core for technical description of the
vulnerability.
. 2008-03-27: Technical details are sent to Comodo team by Core.
. 2008-03-31: Rising team asks Core for technical description of the
vulnerability.
. 2008-04-01: Technical details are sent to Rising team by Core.
. 2008-04-02: Rising team inform Core that the flaw has been fixed in
the Rising AV 2008 version.
. 2008-04-02: Sophos team asks Core for technical description of the
vulnerability.
. 2008-04-07: Technical details are sent to Sophos team by Core.
. 2008-04-11: Sophos team informs that the flaw is found in one of the
antivirus drivers, and fixing it will require a reboot for all of Sophos
Windows customers. Sophos would like to fix the bug in the next major
version (second quarter 2009), in particular considering the fact that
they were unable to come up with any practical use of this vulnerability.
. 2008-04-14: Comodo notifies Core that a fix has been produced.
. 2008-04-14: Sophos informs Core that they will be able to release a
fix to the vulnerability at the end of October 2008.
. 2008-04-21: Core responds that they will reschedule the publication to
April 24th, 2008. Since the vulnerability is not critical, and has been
found using publicly available tools, like the other vulnerabilities
included in the advisory, Core doesn’t see a reason to postpone the
publication of the Sophos bug until October 2008.
. 2008-04-21: Sophos asks Core not to release details of the
vulnerability until a fix is available, and not to publish Proof of
Concept code. Sophos informs that they do not believe that arbitrary
code execution is possible.
. 2008-04-24: Core responds that the advisory does not contain Proof of
Concept code. Core confirms its intention of publishing the advisory,
including the technical description, but decides to postpone it to April
28th, to give the participants more time to coordinate the release of
public information.
. 2008-04-25: Sophos provides additional information, included in the
“vendor information” section of the advisory.
. 2008-04-28: CORE-2008-0320 advisory is published.
*References*
[1] http://www.bitdefender.com
[2] http://www.comodo.com
[3] http://www.sophos.com
[4] http://www.rising-global.com
[5] http://www.matousec.com/downloads
[6]
http://www.matousec.com/info/articles/plague-in-security-software-driver
s.php
*About CoreLabs*
CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs/.
*About Core Security Technologies*
Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide develop and maintain a
proactive process for securing their networks. The company’s flagship
product, CORE IMPACT, is the most comprehensive product for performing
enterprise security assurance testing. CORE IMPACT evaluates network,
endpoint and end-user vulnerabilities and identifies what resources are
exposed. It enables organizations to determine if current security
investments are detecting and preventing attacks. Core Security
Technologies augments its leading technology solution with world-class
security consulting services, including penetration testing and software
security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core
Security Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com.
*Disclaimer*
The contents of this advisory are copyright (c) 2008 Core Security
Technologies and (c) 2008 CoreLabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.