[原创]Avast引起的RPC卡死-软件逆向-看雪-安全社区|安全招聘|kanxue.com

[原创]Avast引起的RPC卡死

发表于: 2017-9-19 19:29 7435

[原创]Avast引起的RPC卡死

goddkiller 活跃值

2017-9-19 19:29

7435

注意：这文章是 2014-1-23 写的，留了很久现在自己也不做TO C的安全了，就把文章整理发出来，留在硬盘也是烂了而已

这个案例是从工作中提取出来的，有少量用户反馈说在用我们的产品的时候会卡死，进而整个系统也卡死。由于我们的程序调用系统提供的函数中他们绝大部分是通过RPC去调用的，所以一开始我就猜到极有可能是卡在RPC调用里面了。后面我自己也重现了这个现象，然后取了DUMP。

下面就开始来分析我们DUMP下来的这个文件。

首先是用!process 0 0 xxx.exe来获取我们程序的EPROCESS地址，然后再!process 0xaaaabbbb看下整个程序的线程有没有什么异样。幸运的是我们很快就找到了一个可疑线程，它的堆栈如下：

THREAD 92bdc4f8 Cid 06f0.0304 Teb: 7ffd6000 Win32Thread: fd9ffa90 WAIT: (WrLpcReply) UserMode Non-Alertable

92bdc72c Semaphore Limit 0x1

Waiting for reply to ALPC Message a1ec8b00 : queued at port 92b54f00 : owned by process 8c93d820

Not impersonating

DeviceMap 8c628e68

Owning Process 92af1738 Image: XXX.exe

Attached Process N/A Image: N/A

Wait Start TickCount 9884 Ticks: 13579 (0:00:03:31.833)

Context Switch Count 1079 IdealProcessor: 0

UserTime 00:00:00.109

KernelTime 00:00:00.156

Win32 Start Address 0x6d5842c8

Stack Init 97af9ed0 Current 97af9828 Base 97afa000 Limit 97af7000 Call 0

Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

ChildEBP RetAddr

97af9840 8408069d nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])

97af9878 8407f4c7 nt!KiSwapThread+0x266

97af98a0 840790cf nt!KiCommitThreadWait+0x1df

97af991c 840b0e75 nt!KeWaitForSingleObject+0x393

97af9944 8423e4dc nt!AlpcpSignalAndWait+0x7b

97af9968 8425fca6 nt!AlpcpReceiveSynchronousReply+0x27

97af99f8 8425514e nt!AlpcpProcessSynchronousRequest+0x276

97af9a60 8c4427b8 nt!NtAlpcSendWaitReceivePort+0xd0

这个堆栈很明显卡在LPC里面了，这个线程在等待回复，可是老是没有人回复它然后就一直卡在那里了。我们可以先通过 NtAlpcSendWaitReceivePort看下里面的参数找些有用的信息，该函数的原型如下

NTSYSCALLAPI

NTSTATUS

NTAPI

ZwAlpcSendWaitReceivePort(

__in HANDLE PortHandle,

__in ULONG Flags,

__in_opt PPORT_MESSAGE SendMessage,

__in_opt PALPC_MESSAGE_ATTRIBUTES SendMessageAttributes,

__inout_opt PPORT_MESSAGE ReceiveMessage,

__inout_opt PULONG BufferLength,

__inout_opt PALPC_MESSAGE_ATTRIBUTES ReceiveMessageAttributes,

__in_opt PLARGE_INTEGER Timeout

);

我们先获取下这个函数的参数

kd> dd 97af9a60 +8 L8

97af9a68 000003b8 00020000 0c7c3fd0 06b8cef4

97af9a78 0c7c3fd0 0920f710 06b8cef4 00000000

看下3B8这个句柄是谁的

kd> !handle 3b8

PROCESS 92a3a988 SessionId: 0 Cid: 05d4 Peb: 7ffdf000 ParentCid: 0230

DirBase: 3e8a8380 ObjectTable: 9468f140 HandleCount: 1261.

Image: AvastSvc.exe

Handle table at 9468f140 with 1261 entries in use

03b8: Object: a31ed180 GrantedAccess: 00120089 Entry: 9468c770

Object: a31ed180 Type: (869e3eb0) File

ObjectHeader: a31ed168 (new version)

HandleCount: 10 PointerCount: 10

Directory Object: 00000000 Name: \Program Files\AVAST Software\Avast\defs\14010700\db_evope.dat {HarddiskVolume2}

这个句柄是AvastSvc.exe这个进程的。好了我们看下LPC的消息处理的服务线程是谁

kd> !alpc /m a1ec8b00

Message a1ec8b00

MessageID : 0x0828 (2088)

CallbackID : 0x1CCEB (117995)

SequenceNumber : 0x00000002 (2)

Type : LPC_REQUEST

DataLength : 0x0064 (100)

TotalLength : 0x007C (124)

Canceled : No

Release : No

ReplyWaitReply : No

Continuation : Yes

OwnerPort : 87485918 [ALPC_CLIENT_COMMUNICATION_PORT]

WaitingThread : 92bdc4f8

QueueType : ALPC_MSGQUEUE_PENDING

QueuePort : 92b54f00 [ALPC_CONNECTION_PORT]

QueuePortOwnerProcess : 8c93d820 (svchost.exe)

ServerThread : 8b3f3470

QuotaCharged : No

CancelQueuePort : 00000000

CancelSequencePort : 00000000

CancelSequenceNumber : 0x00000000 (0)

ClientContext : 06b8ce40

ServerContext : 00000000

PortContext : 00fc00c8

CancelPortContext : 00000000

SecurityData : 00000000

HandleData : 00000000

kd> !thread 8b3f3470

THREAD 8b3f3470 Cid 0190.0abc Teb: 7ff8e000 Win32Thread: 00000000 WAIT: (UserRequest) UserMode Non-Alertable

92bd4d00 NotificationEvent

9685e090 Mutant - owning thread 88a5ad48

Not impersonating

DeviceMap 8b67ab10

Owning Process 8c93d820 Image: svchost.exe

Attached Process N/A Image: N/A

Wait Start TickCount 9915 Ticks: 13548 (0:00:03:31.350)

Context Switch Count 23 IdealProcessor: 0

UserTime 00:00:00.000

KernelTime 00:00:00.000

Win32 Start Address ntdll!TppWorkerThread (0x770903e7)

Stack Init a58efed0 Current a58ef648 Base a58f0000 Limit a58ed000 Call 0

Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

ChildEBP RetAddr Args to Child

a58ef660 8408069d 8b3f3470 00000000 8412cd20 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])

a58ef698 8407f4c7 9685e090 8b3f3470 8b3f356c nt!KiSwapThread+0x266

a58ef6c0 8407b4a4 8b3f3470 8b3f3530 00000000 nt!KiCommitThreadWait+0x1df

a58ef83c 8422b8c0 00000002 a58ef974 00000001 nt!KeWaitForMultipleObjects+0x535

a58efac8 8422b62d 00000002 a58efafc 00000001 nt!ObpWaitForMultipleObjects+0x262

a58efc18 8404028a 00000002 0222f04c 00000001 nt!NtWaitForMultipleObjects+0xcd

a58efc18 770a70b4 00000002 0222f04c 00000001 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ a58efc34)

0222f098 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])

我们可以看到这个服务线程在svchost.exe里面，此时它正在处理消息，但是没有回复我们的请求，我们注意看WAIT: (UserRequest) 这里，正常情况下如果这个线程回复我们的话应该是WAIT: (WrLpcReceive)所以像这种UserRequest的话，一般是由critical section（临界区)或者synchronization object(同步对象)在等待其他线程。因此我们可以看下这些同步对象或临界区是谁的

kd> dt _KMUTANT 9685e090

nt!_KMUTANT

+0x000 Header : _DISPATCHER_HEADER

+0x010 MutantListEntry : _LIST_ENTRY [ 0x88a5af30 - 0x88a5af30 ]

+0x018 OwnerThread : 0x88a5ad48 _KTHREAD

+0x01c Abandoned : 0 ''

+0x01d ApcDisable : 0 ''

kd> !thread 0x88a5ad48

THREAD 88a5ad48 Cid 0190.0ac0 Teb: 7ff90000 Win32Thread: 00000000 WAIT: (WrLpcReply) UserMode Non-Alertable

88a5af7c Semaphore Limit 0x1

Waiting for reply to ALPC Message a1e498e0 : queued at port 92b54f00 : owned by process 8c93d820

Not impersonating

DeviceMap 8b67ab10

Owning Process 8c93d820 Image: svchost.exe

Attached Process N/A Image: N/A

Wait Start TickCount 20756 Ticks: 2707 (0:00:00:42.229)

Context Switch Count 51 IdealProcessor: 0

UserTime 00:00:00.000

KernelTime 00:00:00.000

Win32 Start Address ntdll!TppWorkerThread (0x770903e7)

Stack Init a58e7ed0 Current a58e7828 Base a58e8000 Limit a58e5000 Call 0

Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

ChildEBP RetAddr Args to Child

a58e7840 8408069d 88a5ad48 00000000 8412cd20 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])

a58e7878 8407f4c7 88a5ae08 88a5ad48 88a5af7c nt!KiSwapThread+0x266

a58e78a0 840790cf 88a5ad48 88a5ae08 00000000 nt!KiCommitThreadWait+0x1df

a58e791c 840b0e75 88a5af7c 00000011 8c930001 nt!KeWaitForSingleObject+0x393

a58e7944 8423e4dc 88a5af7c 8c930001 00000000 nt!AlpcpSignalAndWait+0x7b

a58e7968 8425fca6 8c930001 a58e79d4 60000000 nt!AlpcpReceiveSynchronousReply+0x27

a58e79f8 8425514e 8c8f4f00 00020000 00ff37a8 nt!AlpcpProcessSynchronousRequest+0x276

a58e7a60 8c4427b8 00000200 00020000 00ff37a8 nt!NtAlpcSendWaitReceivePort+0xd0

同样的我们看到这个拥有MUTANT对象的线程里面也在等另一个LPC的回应，同样的我们可以看下这里的 NtAlpcSendWaitReceivePort句柄是谁的

kd> dd a58e7a60+8 L8

a58e7a68 00000200 00020000 00ff37a8 001ad21c

a58e7a78 00ff37a8 0227f468 001ad21c 00000000

kd> !handle 00000200

PROCESS 92a3a988 SessionId: 0 Cid: 05d4 Peb: 7ffdf000 ParentCid: 0230

DirBase: 3e8a8380 ObjectTable: 9468f140 HandleCount: 1261.

Image: AvastSvc.exe

Handle table at 9468f140 with 1261 entries in use

0200: Object: 8b3ac728 GrantedAccess: 00100081 Entry: 9468c400

Object: 8b3ac728 Type: (869e3eb0) File

ObjectHeader: 8b3ac710 (new version)

HandleCount: 1 PointerCount: 2

Directory Object: 00000000 Name: \Program Files\AVAST Software\Avast\setup {HarddiskVolume2}

又是指向AvastSvc.exe进程。我们再查看下这个LPC的消息处理的服务线程是谁

kd> !alpc /m a1e498e0

Message a1e498e0

MessageID : 0x07E0 (2016)

CallbackID : 0x25537 (152887)

SequenceNumber : 0x00000026 (38)

Type : LPC_REQUEST

DataLength : 0x0058 (88)

TotalLength : 0x0070 (112)

Canceled : No

Release : No

ReplyWaitReply : No

Continuation : Yes

OwnerPort : 8c8f4f00 [ALPC_CLIENT_COMMUNICATION_PORT]

WaitingThread : 88a5ad48

QueueType : ALPC_MSGQUEUE_PENDING

QueuePort : 92b54f00 [ALPC_CONNECTION_PORT]

QueuePortOwnerProcess : 8c93d820 (svchost.exe)

ServerThread : 92ac8718

QuotaCharged : No

CancelQueuePort : 00000000

CancelSequencePort : 00000000

CancelSequenceNumber : 0x00000000 (0)

ClientContext : 001ad168

ServerContext : 00000000

PortContext : 001ad028

CancelPortContext : 00000000

SecurityData : 00000000

HandleData : 00000000

kd> !thread 92ac8718

THREAD 92ac8718 Cid 0190.11c0 Teb: 7ff82000 Win32Thread: 00000000 WAIT: (UserRequest) UserMode Non-Alertable

885c1f00 Semaphore Limit 0x1

Not impersonating

DeviceMap 8b67ab10

Owning Process 8c93d820 Image: svchost.exe

Attached Process N/A Image: N/A

Wait Start TickCount 21361 Ticks: 2102 (0:00:00:32.791)

Context Switch Count 37 IdealProcessor: 0

UserTime 00:00:00.000

KernelTime 00:00:00.000

Win32 Start Address ntdll!TppWorkerThread (0x770903e7)

Stack Init a68c3ed0 Current a68c3ac8 Base a68c4000 Limit a68c1000 Call 0

Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

ChildEBP RetAddr Args to Child

a68c3ae0 8408069d 92ac8718 00000000 8412cd20 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])

a68c3b18 8407f4c7 92ac87d8 92ac8718 885c1f00 nt!KiSwapThread+0x266

a68c3b40 840790cf 92ac8718 92ac87d8 000000a0 nt!KiCommitThreadWait+0x1df

a68c3bb8 8422acd7 885c1f00 00000006 84080d01 nt!KeWaitForSingleObject+0x393

a68c3c20 8404028a 000000e4 00000000 a68c3be4 nt!NtWaitForSingleObject+0xc6

a68c3c20 770a70b4 000000e4 00000000 a68c3be4 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ a68c3c34)

0285f240 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])

同样这个服务线程也在等待消息处理。在这里我们就得不到其它有用的信息了，此时我在想为什么这个svchost.exe没有回复LPC的请求。要想知道为什么svchost.exe没有回应请求那我们就需要看下这个svchost.exe的所有线程是不是有其他可疑的地方直接!process 8c93d820 ，接着就是找出可疑的线程看下

THREAD 96877288 Cid 0190.06b8 Teb: 7ffda000 Win32Thread: 00000000 WAIT: (UserRequest) UserMode Non-Alertable

96875428 SynchronizationEvent

968761c8 NotificationEvent

87666fb0 NotificationEvent

96876188 NotificationEvent

87666ff0 NotificationEvent

IRP List:

889cd560: (0006,0094) Flags: 00060070 Mdl: 00000000

92bc9a00: (0006,0094) Flags: 00060070 Mdl: 00000000

885be9d8: (0006,0094) Flags: 00060070 Mdl: 00000000

92b11bf8: (0006,0094) Flags: 00060070 Mdl: 00000000

Not impersonating

DeviceMap 8b67ab10

Owning Process 8c93d820 Image: svchost.exe

Attached Process N/A Image: N/A

Wait Start TickCount 7702 Ticks: 15761 (0:00:04:05.873)

Context Switch Count 4 IdealProcessor: 0

UserTime 00:00:00.000

KernelTime 00:00:00.000

Win32 Start Address 0x72414f4c

Stack Init 97b5eed0 Current 97b5e648 Base 97b5f000 Limit 97b5c000 Call 0

Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

Kernel stack not resident.

ChildEBP RetAddr

97b5e660 8408069d nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])

97b5e698 8407f4c7 nt!KiSwapThread+0x266

97b5e6c0 8407b4a4 nt!KiCommitThreadWait+0x1df

97b5e83c 8422b8c0 nt!KeWaitForMultipleObjects+0x535

97b5eac8 8422b62d nt!ObpWaitForMultipleObjects+0x262

97b5ec18 8404028a nt!NtWaitForMultipleObjects+0xcd

97b5ec18 770a70b4 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 97b5ec34)

007df730 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0]) THREAD a52175a8 Cid 0190.0f00 Teb: 7ff92000 Win32Thread: 00000000 WAIT: (UserRequest) UserMode Alertable

a31d7c88 SynchronizationEvent

a31e99b0 SynchronizationEvent

IRP List:

a5258598: (0006,0220) Flags: 00060070 Mdl: 00000000

Not impersonating

DeviceMap 8b67ab10

Owning Process 8c93d820 Image: svchost.exe

Attached Process N/A Image: N/A

Wait Start TickCount 23399 Ticks: 64 (0:00:00:00.998)

Context Switch Count 114 IdealProcessor: 0

UserTime 00:00:00.000

KernelTime 00:00:00.015

Win32 Start Address ADVAPI32!WmipEventPump (0x76fca4aa)

Stack Init a4107ed0 Current a4107648 Base a4108000 Limit a4105000 Call 0

Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

ChildEBP RetAddr

a4107660 8408069d nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])

a4107698 8407f4c7 nt!KiSwapThread+0x266

a41076c0 8407b4a4 nt!KiCommitThreadWait+0x1df

a410783c 8422b8c0 nt!KeWaitForMultipleObjects+0x535

a4107ac8 8422b62d nt!ObpWaitForMultipleObjects+0x262

a4107c18 8404028a nt!NtWaitForMultipleObjects+0xcd

a4107c18 770a70b4 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ a4107c34)

0197fed8 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])

在第一处的线程里面的IRP里面都是类似下面的输出Irp is active with 1 stacks 1 is current (= 0x92bc9a70)

No Mdl: System buffer=a30e5008: Thread 96877288: Irp stack trace.

>[ e, 0] 5 1 92b87308 96875038 00000000-00000000 pending

\Driver\mpsdrv

Args: 00000fc8 00000000 7d008004 00000000

可以看到这个IRP处于未决状态，但是由于这个是同步的，其Completion函数是空的，所以这里会一直等待其它地方处理完成才会返回另一处线程里面的IRP如下：

kd> !irp a5258598

Irp is active with 12 stacks 12 is current (= 0xa5258794)

No Mdl: System buffer=86aa3000: Thread a52175a8: Irp stack trace.

[ 0, 0] 0 0 00000000 00000000 00000000-00000000