The $10,000 Mac Hack

I recently read a comment about this hack wondering how long the author had sat on the exploit rather than reporting it to Apple. It’s a very important point.

My opinion of these “security researchers” is well known: there’s a difference between bird watching and research. Finding yet another buffer overflow isn’t “research.” Creating a new way to secure systems is research. Coming up with whole new classes of attack might be research (along the lines of bioweapon research). Those who hunt new instances of old bugs are collectors of exotic animals, weapon manufacturers, volunteer quality testers, or a half-dozen other categories that have little to do with science or research.

Researchers at the University of Illinois at Urbana-Champaign build a new browser from scratch to help keep hackers at bay. I was incredibly skeptical from the headline. It read to me like “team builds near-useless browser that is probably a bit harder to hack than an unpatched Windows box.” But it’s actually an interesting architecture. I like their early consideration of plugin issue. Rather than banning plugins, sandboxing them till they can’t do anything, or bemoaning that plugin writers will probably be stupid and break security but it won’t be the browser’s fault, these guys actually seem to have considered how to compartmentalize such that the plugin can be compromised without losing the farm. That’s a good security lesson for us all. It’s not about making sure nothing bad ever happens or banning everything that could ever let something bad happen. It’s about making sure that when bad things do happen (and they will), that the damage is contained to the piece that was compromised. And to this feature, wow:

The UIUI team has also designed a browser-level information-flow tracking system to enable post-mortem analysis of browser-based attacks.

That’s a team that “gets it.” You will get hacked. Designing for what you do after you get hacked is a sign of great security thinking.</span></span>

Two posts in a day… but this was a completely different topic.

I’m beginning work on my first Leopard-only application, and so I’m trying out garbage collection. Sure, I’m excited about garbage collection. Sure, I have no great love of keeping track of my retain counts and autorelease pools. But….

It feels really, really weird to not release my variables. I tend to rely on autorelease a lot. I know there are some disadvantages, but I like the fact that it notes your intention when you allocate the memory.

It’s a lazy day for me. That means I’ll probably hack stuff all day.

One of my best friends in the world just sent me a note asking for a good Cocoa reference. I thought I’d pass on the same advice I gave him:

This is the book on learning Cocoa:

Cocoa Programming for Mac OS X by Aaron Hillegass

Third edition is supposed to come out this summer. I’ve read the proofs of the 3rd edition, and it does add some good stuff, but if you’re anxious to get started, I’d get 2nd edition and get started.

To all you aspiring Cocoa developers….

If you want to make a private framework, you need to remember to set the install path for it to @executable_path/../Frameworks. Just copying it into your bundle isn’t good enough. Otherwise your app is going to think it’s in (~)/Library/Frameworks once you package it up and give it to other people.

In related news, PandoraBoy 0.5.1a is now released.

Yes it is true, a new version of PandoraBoy is up, 0.5.1. I haven’t put it into Sparkle yet, and probably will skip it because it only fixes a couple of things (most notably, paid accounts now work correctly). Technically there’s an entire full-screen mode in there now with a plug-in architecture and public framework, but I’ve disabled it because it’s still kind of flakey and doesn’t work very well. I’m going to focus for a while instead on some of the bugs that have been reported and get those cleaned up.

Maybe I’ll play with the new version of ShortcutRecorder that just came out thanks to OmniGroup’s contributions (great company, great products). Hopefully I can get rid of my IB2 dependencies and finally move 100% into XCode3.

And of course I’ve been promising improvements in Sparkle that will help PandoraBoy a little bit, and I more deeply need for my day job. I’ve been mostly working on those during what I consider “day job” hours, but right now core product features are far more pressing than automatic updates. And #1 on my list: collapse the current branch back down to trunk! Ah, subversion, thou viper. Linus was right. There’s no such thing as “CVS done right.” But in truth, it isn’t so terrible, it just isn’t so good either….

Well, I’m spending a little more time hacking PandoraBoy today. It now will compile under XCode3 for anyone playing along at home. I’m hoping to learn a lot this week to move things forward even more. Right now I’m here, getting ready for this. Sometimes I think I picked a good life this time.

Now if I can just get back into my home computer to get my PB todo list…. Back into full-screen mode stuff.

I haven’t forgotten about PandoraBoy, but I’ve been very busy these last couple of weeks. I’m now a full-time Mac programmer, and so I’ve been spending most of my time doing “real” hacking. Next week I go to Big Nerd Ranch for training, so I’ll take PB with me to hack on.

I just built my first kernel extension and begun trying it out. Kernel programming is a whole different world… When it doesn’t work, Gray Screen/Reboot. I’m glad that (a) OSX boots quick, and (b) I have a lot of computers…

I’m trying to waste system resources in a guaranteed way. I have these boxes with 2G of memory, and need to test problems that show up on 512MB machines and I don’t have any 512MB sticks….

As I study Mac OS X Advanced Programming, I think I may be able to do this with mlock() and not have to use a kext. I’ve read other things that suggest that mlock() won’t work the way I want in a user app. So testing is in my future.

Full-screen PandoraBoy has been a major learning experience. Quartz Composer is an incredible tool, but it took me a long time to get rid of the random noise in the picture. First secret: spend some time and read through every patch available, particularly the ones in Tools. It’s important to know what’s available so you don’t spend hours trying to reinvent the basics. And don’t forget that “transparent” defaults to meaning “whatever random memory happens to be on the video card.”

I’ll be spend quite a bit of time trying to improve the interface for the full-screen plugins. I’m trying to make it as easy to write new full-screen modes as to write new screen savers. Once I’ve gotten a second full-screen plugin written, I think I’ll better know how to structure the interface.

I’ve also finally gotten rid of an old, nagging bug where PB would fail to respond to keyboard shortcuts or Applescript. WebKit is a bit funny about plugins (i.e. Flash). I finally tracked down a weird race condition that causes hitTest: to sometimes return the Flash view and sometimes to return the view that contains the Flash view. PB was only handling the more common case, so sometimes you’d get a stray “ERROR: Could not find webNetscapePluggin” error in your logs. Hopefully that’s now fixed.