Thursday, December 18, 2008

Opera, SVGs and Java applets

Opera 9.63 was just released with some security fixes. I reported one of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se issues, but neicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r myself nor Tarquin (a super friendly and knowledgeable Opera security guy) could do anything significant with it, despite feeling uneasy about cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 feature.

The issue is this: when an SVG image is included via an 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 SVG tags such as .

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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 tag. The Opera guys even checked that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 unusual context of executing due to an tag gets cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 domain correct (that of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 img resource, not cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hosting page). By cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 time I inquired about this, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y had already checked.

I continue to be impressed with Opera; cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ft via SVG attack.

Not many browsers support this advanced feature. Aside from Opera, both Safari and Chrome support this. But cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y do not render Java applets in SVGs in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 tag context.

If you can think of a scenario where cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se embedded applets could cause more trouble that I've realized, please leave a comment or mail me :)

Wednesday, December 17, 2008

Firefox cross-domain text cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ft....

... and a reappearance of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 "302 redirect trick".

Here's cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 second bug from my PacSec presentation, and it's anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r Firefox one; kudos to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Firefox security team for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir responsiveness. It's fixed in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 recent 2.0.0.19 and 3.0.5 releases.

It involves, yes, a cross-domain







If you are logged in, you'll see "3px" vs. "0px" ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rwise.

You'll also appreciate from this that any CSS property value is stealable cross-domain, assuming cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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.
1 comment:

Friday, August 29, 2008

Ode to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bug that almost was

This post is a tribute to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hundreds of bugs that never quite were serious, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 emotional roller coaster ride on which cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y take researchers.

Some brief background. The skill in finding serious bugs cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se days isn't in being a demon code auditor or a furious fuzzer; cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are thousands of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se. The skill lies instead in finding a piece of software, or a piece of functionality, that has cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 curious mix of being important yet not having seen much scrutiny.

Onto today's almost-bug: an interesting integer condition in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same native code, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365reby 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 way it is formulated, returned a signed int. Therefore, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 assignment to cenlen triggers sign extension. This means that cenlen can end up being negative, racá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r than cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 stated intent of being treated as an unsigned 32-bit quantity. The negative value will of course bypass cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 security check and lead to subsequent undesirable state. (Note that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 best fix is not to enhance cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 check, but to add a cast to unsigned int to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r 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, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Sun JVM process seems to spray mappings liberally through cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 address space, leaving no room for a contiguous 2Gb mapping.

The same sign-extension bug exists in ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r parts of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ZIP handling, and leads to some interesting negative values getting to some interesting places. But lower-level sanity checks save cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 day in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cases that I could find.

A zip file capable of triggering cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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.

Monday, August 25, 2008

A dangerous combination of browser features

As browsers gain more and more features, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 possibility increases for interesting or dangerous interactions between cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se features. I was recently playing with a couple of new browser features -- and SVGs -- and found a cross-domain leak in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 development version of Webkit:

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

Fortunately, no production versions of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 major browsers are affected - and forearmed with this information, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y can keep it that way. The only production browser I found that supports all of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 required pieces is Opera 9.52, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y deserve some serious credit for getting cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 security check correct.

Thursday, July 31, 2008

Buffer overflow in libxslt

libxslt is an interesting attack surface; cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are various places in which it is used to process untrusted stylesheets. This includes some browsers, although namespace issues seem to prevent cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 affected code from being reached in a browser context.

Within libxslt itself, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re 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 furcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r exploitation opportunities here.

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

Tuesday, July 29, 2008

On FTP, SSL and broken interfaces

Oh what a fun day I just had piecing togecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 stream, and less obviously, truncating cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 stream. The interesting attack to truncate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same on a healthy, cryptographically guaranteed EOF. But what does it do it if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 attacker forces cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 TCP stream to close with a faked FIN? It also returns 0. That's right - no indication of any problem at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 API level. If you want to check what is going on, you need to eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r check cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 SSL error code, in case cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re 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 anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r topic).

The OpenSSL API for SSL_read() is broken. You can phrase why in various ways: it violates cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 classic example.

A quick survey of popular FTP servers reveals that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y don't SSL_shutdown() cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir uploads. It's a direct knock-on from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 SSL_read() broken API. If it returned error on forced connection shutdown, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n FTP servers wouldn't have ever tolerated buggy clients, and clients would have been forced to correctly shutdown cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir connections.

Thanks to Tim Kosse of FileZilla fame for putting me on to this area by checking for secure connection shutdown in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 latest version of FileZilla, exposing an interoperability bug in vsftpd's SSL downloads.

Monday, July 14, 2008

Lame OpenOffice PCX crash

Sorry for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 original deal was. I'm only posting because this blog serves as an RSS feed for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 scary.beasts.org main vuln list.

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

A more interesting OpenOffice observation is in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 works.

Sunday, July 13, 2008

Fancy an exploitation challenge?

So you think you're 1337? Check out cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se 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.

Friday, July 11, 2008

iPhone Safari update fixes old libxslt version

This story is both interesting and boring at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same time.

Boring because I didn't find anything new -- I just noted cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 applicability of something old to Apple's Safari. I've made sure to credit cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 finder of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 old bug that applies to Safari; unfortunately not everyone in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 security industry credits cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 original finder of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bug when noting it applies to a new context.

The story is interesting because it illustrates cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ongoing challenge of depending upon complex open source libraries. As cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se move forward, you need a good way of keeping on top. The public nature of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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

Wednesday, March 5, 2008

Sun JDK image parsing vulnerabilities

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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 heap buffer overflows (in both cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 old and new advisories) relies on that fact that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 JDK environment has a SEGV handler installed. These particular heap overflows will always try and perform massively long copies, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365refore faulting as part of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 copy. This would be a DoS only apart from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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.

Wednesday, February 27, 2008

Buffer overflow in Ghostscript

Given cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se 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.

Wednesday, February 13, 2008

Your FTP / SSL solution is really secure, right?

Well no, not really. Almost all real-world usage of FTP over SSL has problems whereby cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir own SSL certs and manually enable sending cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 server, you've already lost on usability grounds.

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

Saturday, February 2, 2008

Sun JDK6 XXE protection broken

Sun released JDK6u4 which fixes a possibly nasty issue where one of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 XXE protection methods for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 common web service frameworks do XXE protection. It's possible to ban DTDs outright, but I'd suspect more common would be to use cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 broken parser property http://xml.org/sax/features/external-general-entities.

I'd love feedback on specific affected technologies.
Newer Posts Home