Advisory: Adobe Air 1.1 JavaScript execution security vulnerability

By Chris Weber | November 18, 2008

Adobe released a patch and bulletin for an issue I reported back in May.  The issue is really in WebKit, and many products seem to be affected.

A vulnerability has been identified in Adobe AIR 1.1 and earlier that could allow an attacker who successfully exploits this potential vulnerability to execute untrusted JavaScript with elevated privileges. An Adobe AIR application must load data from an untrusted source to trigger this potential vulnerability. In addition, AIR 1.5 includes a Flash Player update to resolve the critical issues outlined in Flash Player Security Bulletin APSB08-22, as well as issues included in Flash Player Security Bulletins APSB08-20 and APSB08-18. Adobe recommends AIR customers update to Adobe AIR 1.5. These issues are remotely exploitable.

Posted in Unicode, advisory, cross site scripting, javascript, testing | Tagged , , | Leave a comment

Advisory: BOM’ing Firefox’s Javascript Interpreter

By Chris Weber | October 1, 2008

Damage: Filter evasion, cross-site scripting
Exploit: Insert Unicode byte order mark (BOM) U+FEFF into javascript statements to bypass filters.
Root Cause: character absorption/swallowing
Product version: Firefox 3.01 and earlier

Link to Mozilla advisory: http://www.mozilla.org/security/announce/2008/mfsa2008-43.html

Well admittedly this one seems to have little exploitative value compared to some of the others.  But surely someone with more know-how than myself could find a useful exploit for it.

Firefox already knew about this since Dave Reed reported it in February and were working on the fix.  This behavior could lead to all sorts of nastiness, such as enabling cross-site scripting, bypassing or evading HTML filters and WAF’s.  To get to the point, here’s what’s possible by injecting the Unicode BOM U+FEFF in the javascript: <a h[U+FEFF]ref=”javas[U+FEFF]cript[U+FEFF](ale[U+FEFF]rt(’onclick’)”>

This issue was found years ago in Firefox’s HTML interpreter, but left hidden in the Javascript interpreter or maybe reintroduced later?  I’m not sure, but the current issue was only in Javascript, not HTML. The Unicode byte-order-mark (BOM) consists of the character code U+FEFF and is normally used at the start of a file to indicate to the parser the encoding form and byte order.

Bytes Encoding Form
00 00 FE FF UTF-32, big-endian
FF FE 00 00 UTF-32, little-endian
FE FF UTF-16, big-endian
FF FE UTF-16, little-endian
EF BB BF UTF-8

When the BOM sequence occurs in the middle of a file, we might expect it to change the meaning of the string.  In other words, we wouldn’t expect the following to be ignored in valid Javascript: va[U+FEFF]r x = “x”; document.wr[U+FEFF]ite(’ouch’); So yes it seems the above does become valid Javascript.

Maybe the BOM character is stripped prior to hitting the Interpreter, I’m not sure.  But the expected behavior would be an error condition.  The problem may be with the Unicode specification too.  Regarding U+FEFF handling when found in the middle of markup files, they say :

When designing a markup language or data protocol, the use of U+FEFF can be restricted to that of Byte Order Mark. In that case, any U+FEFF occurring in the middle of the file can be ignored, or treated as an error. [AF]

The part that says ‘can be ignored’ might be what’s happening here.  But it seems like the Unicode handler is removing the U+FEFF before passing the content to the javascript interpreter.

Here’s a link to the test case.

Posted in Unicode, advisory, browser, cascading style sheets, cross site scripting, security, software security, xss | Tagged , , | Leave a comment

BabelMap - navigating the spectacle of the seventeen planes

By Chris Weber | September 17, 2008

BabelMap stays open anytime I’m testing Unicode-enabled software for vulnerabilities.  It’s very useful for the advanced search - find all code points with the Zs category assigned, or the white space binary property.

Posted in Unicode, tools | Tagged , | Leave a comment

A shifting HTML5 spec could leave many applications vulnerable

By Chris Weber | September 13, 2008

We get into a dangerous situation when applications start implementing a standards-based specification that’s still in flux.  I think it’s made pretty clear in the HTML5 spec.

Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.

 

Posted in security | Leave a comment

32nd Internationalization and Unicode Conference

By Chris Weber | September 10, 2008

Just got back from the IUC in San Jose and wanted to post my slides.

Posted in Unicode, security | Tagged , | 1 Comment

Unicode root-cause security issues for generating test cases

By Chris Weber | September 9, 2008

When it comes to Unicode implementations, there’s a rich set of test cases to perform. Realizing it is the start. Automating it is the next step.

Most Unicode-related security bugs can be categorized into the following root-causes:

Canonicalization

  • Interpreting non-shortest form (e.g .UTF-8 encoding trickery)
  • Other decoding issues

Absorption (over-consumption)

  • Over-consuming invalid byte sequences or correcting rather than failing
  • When <41 C2 C3 B1 42>  becomes <41 42>

Character deletion and swallowing

  • “deletion of noncharacters” (UTR-36)
  • <scr[U+FEFF]ipt> becomes <script>
  • Use replacement characters instead!

Interpreting Syntax replacements

  • white space and line feeds
  • E.g. when U+180E acts like U+0020

Best-fit mappings

  • When σ becomes s
  • When ′ becomes ‘

Buffer overruns

  • Incorrect assumptions about string sizes (chars vs. bytes)
  • Improper width calculations

Timing issues

  • handling Unicode after security gates
  • Sometimes handling Unicode before a gate can be a problem too! E.g. BOM handling
Posted in Unicode, testing | Tagged , | 1 Comment

Protected: Advisory: Browser BOM’ing for XSS

By Chris Weber | August 26, 2008

This post is password protected. To view it please enter your password below:


Posted in Unicode, advisory, browser, cross site scripting | Tagged , , | Leave a comment

Advisory: Attack of the Mongolian space evaders! (and other Medieval XSS vectors)

By Chris Weber | August 26, 2008

Damage: Filter evasion, cross-site scripting
Exploit: Bypass XSS filters, IPS/IDS, AV, or WAF’s with specially crafted white_space characters to execute XSS attacks.
Root Cause: Interpreting syntax replacements
Product Version: Opera 9.51 and earlier

Or should we call this “Druidic magical symbols enable filter evasion and cross-site scripting“…

If only I had some Danel Clowe skills to illustrate this!  It’s not often we can use Ogham Space Marks and Mongolian Vowel Separators to deliver cross-site scripting attacks.

What am I talking about?  Okay enough fun, read on…

Opera released version 9.52 of their flagship browser about a month ago to address an issue in the way certain Unicode characters were being interpreted as white space.  This behavior enabled cross-site scripting (XSS) attacks which might not otherwise be possible.  Perhaps exploiting this issue would also be useful to evade HTML filters, WAFs, or other detection systems which try to prevent XSS attacks.

The HTML 4.01 specification defines four whitespace characters, and explicitly does not define other cases.  Note to XSS filter developers:  Any character can be treated as whitespace by an HTML4 conforming User-Agent.

The HTML 5 specification defines five types of “space characters”, and explicitly nothing else.   However, the HTML 5 spec is in flux which is a much bigger issue… more on that later.

The Unicode spec assigns binary property meta-data to code points, one of which is the ‘white_space’ property.  In Opera’s case, we could use almost any character with a Unicode white_space property to represent a normal whitespace character like U+0020.

The following characters all get treated as a space.  Making things like:

<a href=#[U+180E]onclick=alert()>

possible. This list includes many of the Unicode characters with the white_space property:

U+2002 to U+200A
U+205F
U+3000
U+180E Mongolian Vowel Separator
U+1680 Ogham Space Mark

Here’s a link to the test case: Opera Unicode white_space

Posted in Unicode, advisory, browser, cross site scripting | Tagged , , | 8 Comments

Code2000 font

By Chris Weber | June 5, 2008

Code2000 is a Unicode-based font supporting a great deal of the glyphs in Unicode 5.1, especially the really important ones like the Phaistos Disk and Phoenician.

Posted in Unicode | Tagged , , | Leave a comment

Fuzzing and detecting heap corruption with Gflags, pageheap, windbg and Image File Execution Options

By Chris Weber | May 30, 2008

It’s time again to do some good ol’ down home fuzzing on Windows and can’t forget to enable full page heap checking, else I could miss some important heap corruption issues. So to remind myself how to do this, let’s see:

1. First off, use a release version of the target application, not a debug! And have windbg.exe and debugging tools installed to c:\debuggers

2. Then, use page heap checking to monitor the page heap for corruption. I could use BoundsChecker, Purify, or the other runtime memory tools out there, but this is free and comes with Windows OS. I’ll use gflags.exe to enable full page heap checking in my process:

c:\debuggers\gflags –p /enable myapp.exe /full

3. This will set some registry key values which I should see now under:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\myapp.exe
GlobalFlag = REG_STRING 0x2000000
PageHeapFlags = REG_STRING 0x3

4. If the application is large and you only want to monitor one loaded dll or module, you can specify pageheap on that module alone with:

gflags –p /enable myapp.exe /full /dlls mydll.dll

5. If you want the target application to run under the debugger every time it launches, then set up the image file execution options again:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\myapp.exe
Debugger = REG_STRING c:\debuggers\windbg -g

Posted in debugging, security | Tagged , , , | Leave a comment