Symantec Blogs: Security ResponseSyndicate content

Peter Ferrie | April 16th, 2007
0 comments

A few days ago, a postto a vulnerability discussion mailing list included a demonstration ofa heap corruption in Windows .hlp files' "bm" section. .hlp files areWinHelp-format Help files, a primitive version of .chm, or CompiledHelp Module-format help files. The "bm" section, or the Bitmap-formatgraphics section, is the part of the .hlp file that contains graphics(icons, pictures, etc.). The poster had discovered the vulnerability byusing a fuzzer to insert random data into the file. However, it seemsthat he did not understand why this vulnerability works.

After digging into the issue, it appeared to me that the filetargets the same vulnerability that was last attacked in December of2004, the WinHelp Phrase Heap Overflow.However, after a careful review, I realized that this heap overflow isnot the same as...

Peter Ferrie | February 19th, 2007
0 comments

A colleague of mine came to see me one morning recently with anunusual result. For reasons that he didn't explain to me (he called it"a secret project"), he had intentionally placed a particular encodingof an invalid instruction near the end of a valid page, next to anunallocated page, then executed that instruction. However, instead ofseeing the expected invalid opcode exception, he was seeing a pagefault. Initially, I thought that it was related to the unexpected LOCKexception bug in Windows that I documented here, but it turned out to be something else entirely.

It turns out that the CPU performs a complete fetch, includingparsing the ModR/M byte, prior to performing any kind of decoding.Thus, because of the instruction encoding that he had used, the CPU wasattempting to retrieve all of the necessary bytes first,before it knew that the...

Peter Ferrie | January 24th, 2007
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...

Peter Ferrie | January 17th, 2007
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
look_op:
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...

Peter Ferrie | January 5th, 2007
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 easier to achieve....