Skypher » Browsers

MSIE 6,7, 8 & 9 insertAdjacentElement NULL ptr

SkyLined — Mon, 12 Apr 2010 12:03:10 +0000

img=new Image(); img.insertAdjacentElement("afterEnd",img);

More details here: http://code.google.com/p/skylined/issues/detail?id=15

Apple QuickTime memory corruption when loading BMP file

SkyLined — Mon, 12 Apr 2010 11:53:01 +0000

From http://support.apple.com/kb/HT4104:
CVE-ID: CVE-2010-0536

Impact: Opening a maliciously crafted BMP image may lead to an unexpected application termination or arbitrary code execution

Description: A memory corruption issue exists in the handling of BMP images. Opening a maliciously crafted BMP image may lead to an unexpected application termination or arbitrary code execution. This update addresses the issue by performing additional validation of BMP images.

More details here:
http://code.google.com/p/skylined/issues/detail?id=11

MSIE 8,9 (X)HTML stack exhaustion

SkyLined — Mon, 12 Apr 2010 11:45:23 +0000

Many nested tags in MSIE can cause stack exhaustion, which can crash the tab and even the entire browser.

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

.... etc...

More details here: http://code.google.com/p/skylined/issues/detail?id=14.

MSIE 9 regular expression related crashes

SkyLined — Mon, 12 Apr 2010 11:32:07 +0000

The following code snippets will crash MSIE 9 platform review. Because this is not a stable release, but a preview of a product in development, it is expected to have a few bugs here and there – so don’t go browsing the web with it .

More details here: http://code.google.com/p/skylined/issues/detail?id=13

Microsoft Windows .ANI file BITMAPINFOHEADER.biClrUsed bounds check missing

SkyLined — Mon, 08 Mar 2010 09:45:20 +0000

Quoting http://msdn.microsoft.com/en-us/library/aa930622.aspx:
typedef struct tagBITMAPINFOHEADER { DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; } BITMAPINFOHEADER;
“If the bitmap is a packed bitmap (a bitmap in which the bitmap array immediately follows the BITMAPINFO header and is referenced by a single pointer), the biClrUsed member must be either zero or the actual size of the color table.”

ANI files stores each frame of the animated cursor as a packed bitmap inside the ANI file. The DWORD biClrUsed member of the BITMAPINFOHEADER of each such bitmap can be used to cause the Windows API functions to allocate any number of bytes and attempt to copy a similarly large ammount of data from the file in memory to the newly allocated memory. The code does not check that such a large ammount of data is available and this can cause the copy operation to read beyong the bounds of the memory allocated for the ANI file. This problem affects Windows XP and Vista but not the newer Windows 7.

This can cause a read access violation if a small ANI file specifies a large value for biClrUsed: the memory copy operation runs beyond the memory allocated for the file data and into unallocated memory. MSIE is an example of an application that uses these Windows APIs to read ANI files, it is also the application that this problem was first detect in. However, there could be other applications that use these API functions.

In MSIE, this read AV is handled by an exception handler, so it does not cause the browser to crash. The read access violation is therefore only visible if a debugger is attached to MSIE. However, this problem can also be used to cause the application to allocate excessive amounts of memory and become unresponsive, using 100% CPU. For MSIE, this seems to affect the x86 version only and not the x64 version. I cannot explain, not have I investigated the exact cause of this difference between these two versions.

Microsoft has confirmed the issue and based on the impact has decided to fix this in Service Packs for the various versions of Windows affected. They cannot provide release estimates for these Service Packs at this time. If you maintain an application that depends on the Windows APIs to load ANI files, you may want to investigate how this issue affects your application and do additional checks on the contents of ANI files before calling vulnerable Windows API functions.

Full details, including case history and repro for this particular bug can be found here.

ASPsh – A remote shell written in ASP.

SkyLined — Thu, 04 Mar 2010 14:37:31 +0000

Today I am releasing another old project called ASPsh. The goal of this project was to create an ASP page that can be used on a server to provide a “command line shell”-like experience when opening the page in a webbrowser. It also allows up- and downloading of files to and from the server. I hope the screen shot below explains what that means.

Source code can be found here.

Internet Exploiter 2 – bypassing DEP

SkyLined — Mon, 01 Mar 2010 15:22:53 +0000

In 2005 I released Internet Exploiter 2, which helped make heap spraying popular in browser exploits. The exploit I released would not work if you had DEP turned on for MSIE. However, I also created a version of the exploit that used ret-into-libc to bypass DEP, which I never released until today.

I am releasing this because I feel it helps explain why ASLR+DEP are not a mitigation to put a lot of faith in, especially on x86 platforms. 32-bits does not provide sufficient address space to randomize memory to the point where guessing addresses becomes impractical, considering heap spraying can allow an attacker to allocate memory across a considerable chunk of the address space and in a highly predictable location. The code in this exploit shows how to abuse this to perform a ret-into-libc attack when you can predict or, through information leakage, determine the location of modules (exe, dll) in the process’ memory.

The source code, which has inline documentation, can be found here.

***UPDATE*** It appears that some people need a little more detail to figure out what is going on:

this exploit targets a bug that was already fixed in MSIE 6.0 in 2005,

This exploit does not defeat ASLR, it only shows how to defeat DEP if ASLR is disabled or if you can bypass it.

Microsoft Internet Explorer 6.0/7.0 NULL pointer crashes

SkyLined — Wed, 20 Jan 2010 10:55:37 +0000

Two crashes caused by NULL pointer dereferences have been discovered in MSIE 6.0/7.0. These issues do not affect MSIE 8.0.

document.createElement(“li”).value=3

document.createElement(“html”).outerHTML

I’ve recently started using Google Code for tracking bugs: an editted version of the history of this bug can be found here.

Advances in heap spraying #1: when size matters.

SkyLined — Mon, 18 Jan 2010 15:08:02 +0000

http://skypher.com/SkyLined/heap_spray/small_heap_spray_generator.html

I’ve created a heap-spray generator. It generates a small piece of JavaScript that sprays the heap using the following customizable settings:

Shellcode, easy to enter using hexadecimal byte values (see also BETA3).

Target address and block size.

heap header size based on target browsers or manual value.

The resulting code is smaller than any heap-spray I’ve seen in the wild:

The heap-spray code itself is just over 70 bytes.

The shellcode can be encoded using a custom-build 7-bit encoding.

Most exploits contain shellcode encoded as “\uXXXX” or even “%uXXXX”. The resulting encoded shellcode data contains 3 bytes for every byte in the original shellcode. Because this is very wasteful, it is quite easy to improve on this by creating a custom en-/decoder. The “7-bit” encoding I created converts the 16-bit characters in the unicode string that contains the shellcode to a series of 7-bit values, which are encoded into latin-1 characters. The resulting encoded shellcode data contains only 1.125 bytes for every byte in the shellcode, a saving of almost 63% compared to conventional encodings.
The heap-spray will of course need some additional code to decode the shellcode, so the combined code+data will only be smaller for large enough shellcodes. Because my decoder is also rather small (just under 130 bytes), the break-even point is just under 70 bytes of shellcode. For a a 100 byte shellcode, you save about 50 bytes and for a 200 bytes shellcode, you save about 200 bytes!

You can try out the heap-spray generator here.

Where’s Waldo SkyLined?

SkyLined — Wed, 21 Oct 2009 12:52:07 +0000