Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Security Response
Showing posts tagged with Vulnerabilities & Exploits
Showing posts in English
Eric Chien | 30 Jan 2007 08:00:00 GMT | 0 comments

We have received some additional Worddocuments that exploit an unpatched Microsoft Word vulnerability. Thesedocuments are detected as Trojan.Mdropper.X. We believe this is a newvulnerability, making it the fifth currently unpatched Office fileformat vulnerability. While these documents are being used in atargeted attack consistent with previous cases, we have receiveddifferent documents that use this same exploit from multipleorganizations. The documents have been each designed specifically forthe targeted organization in both language and content.

The vulnerability could be a slight variation or may be covered bythe existing CVEs and we are awaiting confirmation from MicrosoftSecurity Response Center. Nevertheless, no patches appear to beavailable, so, as always, be careful opening unsolicited Word documents.

Update - Feb 1st, 2007 11:40 UTC: We have receivedconfirmation from Microsoft that the vulnerability being used in theseattacks is in...

Hon Lau | 25 Jan 2007 08:00:00 GMT | 0 comments

We’ve seen many threats using vulnerabilities based on MicrosoftOffice documents over the last year, so it’s no surprise that we haverecently observed new samples of a threat that follows the same theme.This threat named Trojan.Mdropper.W is using the new Microsoft Word 2000 Unspecified Code Execution Vulnerability (BID22225)to drop threats onto a compromised computer. When the infected Worddocument is opened, it uses an exploit to drop some files onto thecomputer. These files are back door Trojans that enable an attacker togain remote access to your computer.

This vulnerability comes on the back of three other recent and unpatched Microsoft Word vulnerabilities, which are:


Peter Ferrie | 24 Jan 2007 08:00:00 GMT | 0 comments

At AVAR 2006,I presented a paper which discussed ways in which virtual machines arevulnerable to detection and, in some cases, forced hangs or crashes.

The paper briefly discusses the two major types of virtual machines("hardware-bound" and "pure software") and the two hardware-boundsubtypes ("hardware-assisted" and "reduced-privilege guest"). The focusof the paper is the different ways in which various virtual machinescan be detected. There are detections for VMware, VirtualPC, Parallels,Bochs, Hydra (though the published methods have since been fixed),QEMU, Atlantis and Sandbox, along with lots of source code.

The slides from the talk are also available, but without thecommentary, they're not quite as interesting. The paper is availablefrom here. The slides are available from...

Matthew Conover | 22 Jan 2007 08:00:00 GMT | 0 comments

Continued from Part 1...

Exploiting double free vulnerabilities: Case 1

The first way that a double free vulnerability can be exploited is when the first free puts the chunk on the Lookaside (which the Windows heap implementation tries to use before the FreeList since it's more efficient). When a chunk is freed to the Lookaside, the Chunk is still marked as busy (that is, Chunk.Flags & BUSY_FLAG is set) to prevent the chunk from being coalesced with the previous/next chunk. That's because entries on the Lookasidelist are meant to be a fast allocate/deallocate (akin to "fast bins" inthe GLIBC and related Unix heap implementations). By contrast, entrieson the FreeList are frequentlycoalesced when a chunk is being freed and the chunk before/after it isalso free (to make larger contiguous chunks of memory available...

Matthew Conover | 19 Jan 2007 08:00:00 GMT | 0 comments

In light of the recent CSRSS double free bug, I wanted to providesome information on the exploitation of double frees on Windows on XPSP2 and later. Prior to XP SP2, double frees were trivial to exploit,but now the security cookie (in each heap chunk) and safe unlinkingchecks make it more difficult to exploit. So this blog entry willdiscuss the exploitability on XP SP2 and later heap implements.

Note: If you're not familiar with Windows heap terminology, pleasereview the slides from our CanSecWest 2004 heap presentation, archivedhere:

Oded Horovitz and I did not look into this topic much in ouroriginal presentation on Reliable Windows Heap Exploitation atCanSecWest 2004. Later that same year, I discussed how to defeat thesafe unlinking check at SyScan 2004, but I did not consider itsrelevance to double free...

Greg Ahmad | 18 Jan 2007 08:00:00 GMT | 0 comments

In my previous post,I talked about the sudden rise in vulnerabilities affecting ActiveXcontrols. In this post, I would like to talk a bit about the technologybehind ActiveX and various steps that may be taken to prevent attacks.

An ActiveX control is essentially an Object Linking and Embedding(OLE) object. OLE allows objects to be shared using Component ObjectModel (COM) technology, which is a model that permits softwarecomponents to communicate with each other. Distributed COM (DCOM) is anextension of COM that allows for the sharing of components over anetwork. ActiveX technology essentially facilitates the functionalityof OLE on the World Wide Web. The controls can run on platforms thatsupport COM or DCOM.

According to Microsoft, ActiveX controls must provide an interface named “...

Peter Ferrie | 17 Jan 2007 08:00:00 GMT | 0 comments

Last year, I found a curious bug in Windows regarding the handlingof certain invalid opcode sequences. At the time, I simply documentedit and then forgot about it. Recently, however, I was reminded of thebug, so I thought that other people might be interested in readingabout it.

Because of the way in which the Intel x86 architecture works, whenan invalid opcode exception occurs, there is no easy way to tell why itoccurred. By this, I mean that without actually looking at the faultingopcode sequence, it's not possible to tell the difference between anunsupported opcode and an invalid use of the LOCK prefix. For thisreason, Windows runs this code:

mov ecx, 4 ;maximum prefix count
mov al, byte ptr es:[esi] ;points to faulting opcode sequence
cmp al, f0h ;looks like LOCK?
je op_lock ;yes
add esi, 1 ;no, continue with next byte
loop look_op...

Greg Ahmad | 16 Jan 2007 08:00:00 GMT | 0 comments

The year 2006 saw the rise of numeroussecurity trends such as attacks against social networks, initiatives byresearchers to sequentially disclose many flaws in Web browsers andoperating system kernels, attacks being used for financial gain, and adramatic increase in the number of vulnerabilities affecting Webapplications. During the last few months of the year, I have noticedanother trend that did not receive much attention. There has been asignificant increase in the vulnerabilities that affect ActiveXcontrols. These vulnerabilities can facilitate an assortment of attacksthat may simply cause the disclosure of sensitive information to anattacker or, in the worst-case scenario, allow them to execute code togain unauthorized access to an affected computer.

During the last few years there has been an increase in the numberof vulnerabilities affecting ActiveX controls shipped by variousvendors. In the year 2001, DeepSight Alert Services reported a singlevulnerability...

Peter Ferrie | 05 Jan 2007 08:00:00 GMT | 0 comments

With the public advisoryby Determina about a double-free bug in a CSRSS message function, theimmediate question was: does it really affect Vista? The short answeris "yes, but not reliably." Arbitrary code execution is possible, butrequires a great deal of luck, though a denial-of-service is definitelypossible.

Why the fuss? Simply put, successful exploitation of the bug allowseven the most restricted user-mode application to elevate itsprivileges to the System level. From there, the kernel is accessibleeven on Vista. Even without entering the kernel, System-levelprivileges allow almost complete control of the system, so thepossibilities are limited only by the imagination.

Of course, that the bug isn't reliable on Vista doesn't mean thateveryone can relax. The bug does affect earlier versions of Windows,where arbitrary code execution is far...

Hon Lau | 03 Jan 2007 08:00:00 GMT | 0 comments

We have received reports of a significantproblem relating to Adobe Acrobat files and Cross Site Scripting (XSS).A weakness was discovered in the way that the Adobe Reader browserplugin can be made to execute JavaScript code on the client side. Thisstems from the “Open Parameters” feature in Adobe Reader, which allowsfor parameters to be sent to the program when opening a .pdf file. Likemost things in life, this was a feature designed for benign usage, butunfortunately somebody has discovered that it can also be used formalicious purposes.

This development is significant for a number of reasons:
• The ease in which this weakness can be exploited is breathtaking. Useof this “feature” requires no exploitation of vulnerabilities on theserver side.
• Any Web site that hosts a .pdf file can be used to conduct thisattack. All the attacker has to do is find out who is hosting a .pdffile on their Web server and then piggy back on it to mount an attack.What this means...