evan_tech

CVE-2009-0521 was actually me: I was poking around trying to make Flash not crash on Linux Chromium and noticed something wasn't quite right. I had just thought it odd; Tavis, the reporter, recognized it as a security problem.

(I really don't intend to post this much security-related stuff. I believe it's just coincidental that I've had a lot lately.)
08:38 pm, 17 Apr 09

freetype bugs

Since we were just talking about font parsing bugs: four more integer overflows in FreeType. Note the reporter (mentioned in the changelogs). Also note, consistent with what [info]ajaxxx had remarked, that the exploits against FreeType historically have not been against the bytecode but simpler parts like the metrics.
12:50 pm, 16 Apr 09

security bugs

http://seclists.org/fulldisclosure/2009/Apr/0129.html:
VIII. DISCLOSURE TIMELINE
06/28/2006 - Initial Contact
06/29/2006 - PoC Requested
06/29/2006 - PoC Sent
10/05/2006 - Vendor Status Update
01/24/2007 - Vendor Status Update
02/12/2008 - Vendor Status Update
03/31/2009 - CVE Assigned
04/14/2009 - Coordinated Public Disclosure
That's a loooong time to sit on a bug.
10:19 pm, 1 Dec 08

dean schools me on assembly

An old friend was in town the past few weeks and we worked together a bit. His background is in "the hacking scene" so I always learn a ton from him. One event in particular for this post: in debugging a crash* where the backtrace indicated a jump to a garbage address, he immediately dropped to disassembly and pointed out the vtable call, and from there worked out the relevant types (what was expected, what was pointed at concretely) by examining memory.

I was struck by this in how different it was from how I'd have approached the problem (which can maybe be summarized as "stare at it really hard"). I can follow assembly when pressed but it would not have occurred to me to start from there. It also struck me how few people I know would even be able to recognize what calling through a vtable looks like in assembly (especially Intel syntax!), and how this is plainly a hole in my education / skill set.

Of course, one of my officemates is one of those people (and he's years younger than me, so that's no excuse). He explained he'd started out programming in assembly because he didn't have access to a compiler when he was little. Some people are just hard core.

* The problem ended up being a subclass's override of a virtual function where the superclass's function changed its type, causing the subclass code to no longer match and override. This was all far removed from the crash, of course. An extra twist of irony was that it only exhibited on a Digg article about Chrome working on Linux.
Helvetireader is the first application I've seen to explicitly call out the Greasemonkey in Chrome work that Boodman and I did. It's a cute hack, too.

Lately Boodman's been thinking about extensions and autoupdate, so his first observation after "Cool!" was "...and it was implemented in the slowest and least secure way possible." The script basically injects a <link rel='stylesheet' ...> in the pages it wants to affect and it sources the CSS from the dude's site. This means you can't verify what code will actually be used when the script runs in the future.

There are two aspects that cause worry. One is that CSS can be a vector for attacks. My Googling attempts have mostly failed me to find the current state of the world, but at some times some browsers have been known to execute JavaScript expressions from within CSS. Going back to LiveJournal attacks, the Firefox XBL change got LJ too.

The other is that, assuming the owner of that site doesn't end up attacking you (here's one attack I've seen: buy his domain name from him, then put a malicious file at exactly the same URL) is that HTTP is insecure. Historically people haven't cared much about this but it's become more of a problem now that laptops grab wifi from anywhere. (On the other hand, not even SSL will help casual users much if they learn to just click through man-in-the-middle dialogs.)

What's the lesson? I guess it's that you have to make being fast and secure easier than the alternatives if you people to do it. Nobody, myself included, cares much about fast/secure when you're just making a hack.
10:51 am, 25 Nov 08

mime sniffing

One of the many fortuitous events that made Chrome what it is was getting a bunch of rock star interns. Adam has written a bunch of papers on browser security and has a new paper up on XSSes related to mime sniffing: Secure Content Sniffing for Web Browsers or How to Stop Papers from Reviewing Themselves. The subtitle refers to the fact that the paper submission site that this paper was submitted to was itself vulnerable to one of these attacks.

Due to their orthogonality to "traditional" XSS, these sorts of attacks still affect sites that are otherwise pretty good in terms of input handling. I recall, when I first read about these attacks, I was able to make a proof of concept XSS against LiveJournal. When I showed the attack to [info]brad, it amusingly turned out that had already written code to defend against the problem but hadn't yet flipped the switch, so he fixed it within a few minutes. But as the paper illustrates, many other sites (like Wikipedia*) are vulnerable.

* Update: having read more now, I see Wikipedia uses the same defense LJ does; it's just the default configuration of Mediawiki that is vulnerable.
10:39 am, 22 Jan 08

wordpress admin bug

Check out this lol-tastic Wordpress vulnerability fix. And then there's also two followup patches.

(PS: [info]zenspider posted this on Reddit which prompted more comments.)
08:17 am, 14 Jan 08

upnp/flash vulnerability

Not to reduce their work, but this article on UPnP "hacking" [site's currently not loading very reliably] uses a lot of words to make a small point. So here it is in shorter form:
  1. Many (most) routers use UPnP for configuration, which uses SOAP over HTTP.
  2. Despite there being an autodiscovery phase to UPnP that involves non-HTTP packets, you can guess a router's IP anyway and you don't need to do autodiscovery to run commands.
  3. Flash lets you set arbitrary HTTP headers and POST to arbitrary hosts. This is standard XSRF -- the POSTing could be done with DHTML, so Flash is just needed to set the SOAP header.
  4. Therefore, malicious Flash can run port-opening commands on your router.
Opening ports doesn't require a password (since software like Skype wants to be able to do it). They claim you can also change the DNS server or admin credentials, which seems to me like it ought to need a password, but maybe they're relying on people leaving default passwords.
03:14 pm, 1 Jan 08

tireIronNinja

So Dean made this sketchy program called "socketNinja", not really intending to distribute it, and then it became part(?) of Metasploit and distributed. The comments at the top were never updated, and remain:
# Yo yo, this be da socketNinja.
# Alpha-2.0 release
# Distribute and get a visit from tireIronNinja
which is fine and good until someone ITPs it for Debian and non-native English speakers on debian-legal try to unravel it. See the thread. I laughed.
10:20 am, 13 Oct 05

paul graham

I was excited to see Paul Graham speak at OSCON, but I left disappointed. In his writing you get the hint of a smart person enjoying writing and persuasion; in person it was easier to see that he's some Harvard kid who got lucky with a startup and became the sort of megalomaniac you'd expect. And with that in mind his writing took a completely new tone.

So it was refreshing to stumble across this analysis of Hackers and Painters by a Real Painter who calls bullshit on the whole thing.

(Speaking of calling bullshit, this week's Everybody loves Eric Raymond was hilarious.)