Video Screencast Help
Security Response
Showing posts tagged with Vulnerabilities & Exploits
Showing posts in English
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: http://www.cybertech.net/~sh0ksh0k/projects/winheap.

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
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...

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...

Ollie Whitehouse | 30 Dec 2006 08:00:00 GMT | 0 comments

Collin Mulliner gave an updated version of his presentation at 23C3 in Berlin titled ‘Advanced Attacks Against PocketPC Phones’ (we originally blogged about it in August). As I previouslymentioned, one of the vulnerabilities he discussed had, to myknowledge, still not been patched. Well Collin confirmed this in hispresentation and also released a working exploit for the...

Vincent Weafer | 28 Dec 2006 08:00:00 GMT | 0 comments

The two most common questions I hear around this time of year are:what do you think the biggest trend of the year was and what do youthink the biggest threat next year will be. After outlining a year in review, let’s spend a little time on what we may expect to see in the next 12 months.

Obviously, the debut of a new operating system brings with it newfeatures for both the research community and malicious code authors toscrutinize. It’s simple to expect that we’ll see new attack attempts onMicrosoft Vista. What’s more interesting are trends we’re likely to seethat don’t even touch the physical hard drive of a computer. Web 2.0technologies have already begun to capture attacker interest andmotivation. As adoption continues to grow and dependence on these Webapplications increases, the impact and frequency of these issues willrise.

Consider the...

John McDonald | 22 Dec 2006 08:00:00 GMT | 0 comments

A vulnerability has been discovered in theway the Windows Client/Server Runtime Server Subsystem (CSRSS)processes a type of system message referred to as the HardErrormessage, reportedly allowing a logged on user to execute arbitrary codein the CSRSS.EXE process and elevate their privileges to SYSTEM level.The vulnerable code is present in the new Vista operating system, aswell as Windows 2000, XP and 2003.

When certain events occur within the operating system, a HardErrormessage is sent to CSRSS containing the caption and text of a messagebox to be displayed in order to notify the user of a critical systemerror. The HardError message is handled by a function in WINSRV.DLLwhich returns pointers to the caption and text of the message box. Ifthe caption or text parameters are prefixed with certain characters,the function erroneously frees the buffer holding the text and returnsa pointer to freed memory. After the message box is closed by the user,the same buffer is then...

Robert Keith | 20 Dec 2006 08:00:00 GMT | 0 comments

December 9, 2006, marks the day when long standing contributor to the PHP Security Response Team, Stefan Esser, retired.He has stated a few reasons for this latest move, primarily focusing on(in his opinion) the lack of response from his fellow colleagues and anextended delay in the patching of known vulnerabilities. Possiblyanother example of how some individuals or groups may choose to view “responsible disclosure.”

Over the years, SecurityFocus has reported on multiple vulnerabilities affecting PHP, such as BIDs 20879 (PHP HTMLEntities HTMLSpecialChars Buffer Overflow Vulnerabilities), 19582 (PHP Multiple Input...