神刀安全网

新机制,新考验:Windows10(14316) Linux子系统分析

0.背景

在build 2016大会上,微软宣布windows10 中将原生支持bash,并且号称在windows中加入了一个Linux子系统(Windows Subsystem for Linux),而不是一个虚拟机。而后在发布的win10 14316(x64)更新上就开启了bash功能,但32位版本没有bash。

笔者随即下载了14316想体验一下windows上执行bash命令,并且想了解这个Linux子系统机制的实现。

新机制,新考验:Windows10(14316) Linux子系统分析

一.介绍

首先打开system32/bash.exe后,随便输入一个ls命令,通过procmon发现有进程访问了C:/Users/xxxxx/AppData/Local/lxss/rootfs/bin/ls文件。

新机制,新考验:Windows10(14316) Linux子系统分析

随即发现了linux根目录挂载在C:/Users/xxxxx/AppData/Local/lxss/rootfs,可以看到目录结构和ubuntu基本一致。

新机制,新考验:Windows10(14316) Linux子系统分析

反过来看到访问ls这个elf文件的进程比较奇怪,procmon无法显示进程名字,而且挂上调试器还会发现这个进程对象内不仅没有名字,也没有section,peb等信息。

二. Pico Process

这种没有名字的进程称为pico process,也就是ELF的宿主进程。关于picoprocess介绍: http://research.microsoft.com/en-us/projects/drawbridge/#Picoprocess 。简单来说Pico Process是一种Container,实现drawbridge沙盒技术的一种机制,并且之前被微软毙掉的“Project Astoria”项目也用到了lxcore+picoprocess这种技术。现在微软把这种技术应用到了win10 linux子系统当中。

Picoprocess 统一由 PspCreatePicoProcess 创建,而 PspCreatePicoProcess 里面主要的工作是由PsCreateMinimalProcess实现的,PsCreateMinimalProcess这个函数的名字像是用于创建一个精简进程,实际上确实也是这样。PsCreateMinimalProcess里面会调用PspAllocateProcess,PspAllocateProcess函数本身的功能是用来创建EPROCESS对象,进程地址空间,PEB等信息。

PspAllocateProcess函数的原型大致如下:

NTSTATUS  PspAllocateProcess(               void *ParentProcess,               int   PreviousMode,               void *ObjectAttributes,               char  Protection,              char  SignatureLevel,               char  SectionSignatureLevel,               void *SectionObject,              void *TokenObject,               int   Flags,               void *UserProcessParameters,               int   bSystemToken,           OUT int   a12,           OUT void *Process)

而PsCreateMinimalProcess中调用PspAllocateProcess的参数如下图所示,可以发现ObjectAttributes,SectionObject,等都为NULL,这也论证了之前我们看到picoprocess没有进程名,没有用户空间信息等现象。

新机制,新考验:Windows10(14316) Linux子系统分析

再回来看PspCreatePicoProcess这个函数的调用栈,可以看到ring3的调用是由PsPicoSystemCallDispatch这个函数分发到lxcore驱动中的,这里需要引出另一个东西:PicoProvider

新机制,新考验:Windows10(14316) Linux子系统分析

三. PicoProvider

Nt导出了一个函数PsRegisterPicoProvider提供注册一个PicoProvider,在目前只有lxss.sys会调用这个接口,lxss.sys和lxcore.sys这两个驱动负责实现linux子系统的大部分功能。Lxss.sys作为一个boot start driver会在初始化时调用lxcore.sys->PsRegisterPicoProvider,而且PsRegisterPicoProvider在系统启动后只允许调用一次,在所有boot driver初始化完毕后,nt会把PspPicoRegistrationDisabled设置为TRUE,从而禁止以后所有的PsRegisterPicoProvider调用,也就是说当前系统只允许存在一个Provider。

新机制,新考验:Windows10(14316) Linux子系统分析

注意因为目前最新的符号只是14295,14316的符号微软还没有放出,但lxss.sys相关的文件在14295就存在了并且大部分功能nt中已经使用了,只是上层机制并没有实现。所以笔者使用14295的符号配合14316文件来分析lxss内核相关机制,如有不正确欢迎指出。

PsRegisterPicoProvider的原型大致如下:

NTSTATUS PsRegisterPicoProvider(
IN PICO_INTERFACE *PicoInterface, OUT PSP_INTERFACE *PspInterface ); struct PICO_INTERFACE { __int64 cbSize; //目前只支持0x48,不排除以后会有EX PVOID PicoSystemCallDispatch; PVOID PicoThreadExit; PVOID PicoProcessExit; PVOID PicoDispatchException; PVOID PicoProcessTerminate; PVOID PicoWalkUserStack; PVOID LxpProtectedRanges; PVOID PicoGetAllocatedProcessImageName; } struct PSP_INTERFACE { __int64 cbSize; //目前只支持0x60 PVOID PspCreatePicoProcess; PVOID PspCreatePicoThread; PVOID PspGetPicoProcessContext; PVOID PspGetPicoThreadContext; PVOID PspGetContextThreadInternal; PVOID PspSetContextThreadInternal; PVOID PspTerminateThreadByPointer; PVOID PsResumeThread; PVOID PspSetPicoThreadDescriptorBase; PVOID PsSuspendThread; PVOID PspTerminatePicoProcess; }

Lxss通过PsRegisterPicoProvider向NT提供一组PICO操作接口,以获取系统调用分发、进线程退出、异常访问等消息、自己进行处理。并且会获取NT的一组进线程操作接口,用于对nt进线程进行操作。其中有一个PICO接口PicoGetAllocatedProcessImageName,比较感兴趣,因为之前提到了我们用procmon观察pico process是没有名字的,并且内核调试器也无法看到名字,如果能知道pico process对应哪个ELF会对分析有很大帮助。

通过分析,Pico Provider把这个接口提供给NT,在NtQuerySystemInformation获取进程名相关信息的时候,正常情况下会从EPROCESS->SeAuditProcessCreationInfo中取进程名信息,但如果发现这是个pico process则调用PicoGetAllocatedProcessImageName获取。所以逻辑上说NT已经做了对pico process的兼容,但为什么procmon还是无法获取进程名?果然笔者自己试了下用最简单的CreateToolhelp32Snapshot是可以轻松枚举到elf进程相关的名字。

所以procmon可能并不是用标准接口来获取进程名字的。

新机制,新考验:Windows10(14316) Linux子系统分析

但pico process的进程名保存在哪里呢?通过分析这个函数,发现pico process对应的ELF路径信息保存在EPROCESS->PicoContext +0x15b0处,而PicoContext是在创建pico process的时候,由PspCreatePicoProcess设置的,保存了pico process的各种信息。用一个简单的脚本,用来遍历当前系统的pico process的名字信息,这是当我使用bash执行一个wget下载任务的时候的pico进程信息:

新机制,新考验:Windows10(14316) Linux子系统分析

继续说回PsRegisterPicoProvider,PICO Interface中的PicoSystemCallDispatch也比较重要。负责分发pico process传来的系统调用,用于picoprocess和provider进行通信。在pico process的一次系统调用中,当ring3代码sysenter后,内核入口为KiSystemCall64,如果当前thread->_DISPATCHER_HEADER中设置了Minimal标志位,则KiSystemCall64会调用nt!PsPicoSystemCallDispatch进行pico相关分发,不走原始的sdt分发表。Lxcore!LxpSyscalls保存这个分发表的地址。

这是打印的部分分发函数,类似SDT表一样,仍然是通过rax作为id分发,但参数的传递和走sdt的有一些不一样。使用rdi,rsi,rdx,r10传递参数。

(分析过程中还发现14316后多了一张新的SDT表KeServiceDescriptorTableFilter,当一个线程flag被设置为RestrictedGuiThread时,则使用KeServiceDescriptorTableFilter这张表,这张表会限制很多native api的调用,主要限制edge等进程调用win32k等函数,做更严格的安全性隔离,不过目前KeServiceDescriptorTableFilter的内容还是和普通的SDT一样,应该还未使用)

新机制,新考验:Windows10(14316) Linux子系统分析

我们来看下lxcore提供给Linxu子系统一些功能的实现。比如当我们使用bash创建一个ELF进程的时候,lxcore的调用流程大概是:LxpSyscall_FORK->LxpThreadGroupFork ->LxpThreadGroupCreate –>PspCreatePicoProcess。PspCreatePicoProcess在之前PsRegisterPicoProvider的时候已经从NT中获取了,所以lxsscore可以操作nt的进线程,但对于没有向NT获取响应的接口的其他功能呢?

对于文件系统的操作则直接调用相应的nt api,而并非直接和文件系统打交道,比如当使用rm命令删除一个文件的时候,调用流程:LxpSyscall_UNLINK->LxpUnlinkHelper->VfsPerformUnlink->VfsUnlinkChild->LxDrvFsRemoveChild->LxDrvFsDeleteFile->ZwSetInformationFile,其中会通过LxDrvFsDeleteFile 会使用IoCreateFile打开文件,再进行删除。 lxcore.sys中实现了一套VfsXXXX接口向上虚拟了VFS,向下使用LxDrvFsXXXX的一组API提供文件访问能力。

对于网络的操作,分为UNIX协议簇和INET协议簇,两个有不同的分发表,比如当上层发送一个UDP包的时候,lxcore的调用流程: LxpSyscall_SENDMMSG->LxpSocketSendMultipleMessages->LxpSocketInetSendMessage->LxpSocketInetSend->LxpSocketInetDatagramSend->afd!WskProAPISendTo。最终会进入到afd执行相应的功能。这是打印出来的lxcore使用的Afd相关函数:

新机制,新考验:Windows10(14316) Linux子系统分析

再其它的一些,比如获取当前系统信息,lxcore也是直接调用Nt相应的函数获取,例如date命令,lxcore通过LxpSyscall_CLOCK_GETTIME->KeQuerySystemTimePrecise获取。

四. 注入Pico Process

最后试了一下注入到pico process,打算注入进去调用一下pico process的分发表,由于pico process没有section对象所以无法用远程线程注入。最后使用SetThreadContext方法注入到了pico process进程。虽然可以注入成功,但windbg是无法调试pic process的,因为lxcore接管了pico process的异常分发,nt!KiDispatchException中如果发现异常在pico thread中,则使用PicoDispatchException处理异常,lxcore中使用APC模拟signal机制处理进程通信与异常分发。

五.总结

目前来说LxpSyscalls目前包含0×138个调用,而且有些调用目前内部没有逻辑实现,所以微软在未来会逐渐完善各种命令的支持。上面简单分析了一下lxcore对于linux子系统操作的支持,当然只是部分操作,还有一些比如ELF加载,内存管理,设备管理等都还没有分析。但从目前已经分析的结果来看,微软确实是自己实现一套linux子系统支持,并不是一个Linux虚拟机,所以执行效率会好很多,比如pico process的进程的时间片分配和原生的process基本一致。但是缺点也是有,增加了一套lxss机制后,同时也增加了复杂性,也就是说win10以后可能会面临win和linux二进制安全的双重考验,这可能对windows的安全性保障又增加了新的难题。

*投稿:腾讯电脑管家(企业账号),转载请注明来自FreeBuf黑客与极客(FreeBuf.COM)

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 新机制,新考验:Windows10(14316) Linux子系统分析

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址