F-Secure’s iAdware

F-Secure reports that they’ve received a “proof of concept” adware program for our favorite operating system. As usual, details are scant (and people complain about secrecy from OS vendors releasing patches! Jesus, I’m really sick of the “I know something you don’t know, and I’m an expert, so it’s best that you don’t know” attitude from these security companies…).

Anyway from a quick reading of the paragraph it looks like the proof of concept is using either $LD_LIBRARY_PATH or $DYLD_INSERT_LIBRARIES (or the like; man dyld for full details about some of the library substitution environment variables available on OS X) to override standard C library functions and replace them with calls to system(”open -a Safari URL“). Contrary to Ars Technica’s article on the program, I don’t think this has anything to do with the much-maligned input managers or anything Cocoa-specific, though I could be wrong. Reason being: in order for this to work within an application, you’d need to override the system call, i.e., if you intercept malloc() you’d better damn sure return what the caller expects malloc() to return, otherwise the host application will quickly crash and your adware isn’t going to be particularly long-lived. You’d have to pair this approach with writing to ~/environment.plist, and you might have to use $DYLD_FORCE_FLAT_NAMESPACE also, the latter of which causes some applications to break. But if you’re writing adware, you probably don’t care too much if things start breaking on the user’s computer, I guess.

So, input managers, however, have a specific (and rather small) set of entry points on which they’re called; most “haxies” which use the input manager vector only work because they have intimate knowledge of one very specific version of one very specific application, so that the described program works with a number of applications seems to suggest that this isn’t the vector. Sure, you could go this route for your adware — but it’d be tricky; you’d have to do some introspection to see what you can set up for your ad callback in the host application; plus, I’m pretty sure that input managers are only loaded in Cocoa applications. The really cryptic “screen shot” F-Secure has posted seems to be written in plain C — though with the level of technical detail we’ve got here in this disclosure that screenshot could be just totally made up, who knows. I mean, give me more than 40 column text to work with, guys.

So anyway assuming that this program does use the dyld debugging facilities to inject some ad-opening code — so what? In order to get this or even an input manager onto my system you’ve still got to trojan me. Okay, that’s fine, the stuff that I’m up to on the Internet isn’t always on the up and up, sure. But you know, you don’t have to go to the trouble of using either the dyld or the input manager vectors — you could just write an application which has the LSUIElement value set in its property list, open no windows, and mark the application as launch-on-startup. Then your code could be so much simpler! while(1) { sleep(30); system(”open -a Safari http://www.stuffonfire.com/“); }. Brilliant! I’m totally going to write this and become the lord of all Mac OS X botnets.

Adware is kind of a funny thing. It’s not really in the concern of computer security research IMHO as it’s really more of a payload of an attack than a vector, and as such it’s not really very novel. It’s not particularly silent by design, either, so the author just needs to make sure that his or her application is just out of reach of the average user to uninstall. Are input managers out of the reach of the average Mac user? No idea, probably. Again, this is just an exercise in obfustication and not anything particularly interesting.

In conclusion it really sucks that so many of these reports of Mac OS X theory exploit rumor programs are so light on the technical details, makes it utterly impossible to discern the truth from the smoke and mirrors. And for security companies, I guess that’s probably the whole point.