Brain.A versus Bagle.AG
I was making it through my feeds earlier, and on the F-Secure blog saw a visual structural comparison of how the newer Bagle.AG compares to an older piece of maliciousness (Brain.A) from 1992:
Can anyone spot the five small differences between these two pictures?Brain.A fits into a few sectors and consists of around a dozen functions. Bagle.AG weighs over 100 KiB unpacked and it is built from more than a hundred functions.
I'm aware of this stuff because I follow it (various forms of malicious authoring, as well as their detection and defense, are easily one of the more fascinating areas in computer research right now), but a picture really is better than one thousand words sometimes.
I'll be talking about more about this kind of thing soon, as I already meant to before MacWorld, but I've been heartened to hear Apple is actually very worried about this sort of thing internally, and trying to take some steps on the Intel build of Mac OS X that they'd ignored on the PowerPC simply because no one was targeting it in a mass way -- and they were willing to play the odds. With the skill level on x86, those odds shifted decidedly in the other direction.
Posted by drunkenbatmanJanuary 22, 2006, at 07:21 PM
Comments (11)
Posted by: tragek at January 22, 2006 09:59 PM
I adore F-secure's weblog. Alas, I have no use for their software (using freebsd on the desktop afterall. I mean, I could install their workstation edition, and run it under linux emulation, but somehow I get the impression it would be rather pointless. Buffer overruns and security problems worry me more than viruses).
It amazes me though, that it was only 19 years ago that the first known virus was spread.
Posted by: Other_Matt at January 22, 2006 11:59 PM
Not only that, but having a relatively young OS, with relatively few legacy compatibility requirements (well, compared to something like Windows) means that they have more opportunities now to do things like this.
Admittedly, we were saying that 10.4 was supposed to be the _mostly_ stable version of the OS core interface wise, if we're _now_, with the Intel version of things, trying to lock things down, I think we waited a bit too long. Or are we saying that the Intel version has all along been built with these priorities in mind?
Posted by: Abhi Beckert at January 23, 2006 02:22 AM
"Or are we saying that the Intel version has all along been built with these priorities in "
Seriously, there aren't that many differences between the intel and ppc mac os x. The idea is to keep them as similar as possible.
However it's pretty safe to say security has been on the mind of apple's developers for a long time, and even if they haven't been implementing much security stuff there's still a good chance they've been coding with the intention of locking it down one day (which is the next best thing to locking it down immedietly).
Posted by: Uli Kusterer at January 23, 2006 04:41 AM
>>However it's pretty safe to say security has been on the mind of apple's developers for a long time, and even if they haven't been implementing much security stuff there's still a good chance they've been coding with the intention of locking it down one day
Not so sure about that myself, especially considering how Safari suddenly started opening every application in sight and even auto-installed Dashboard Widgets... I could go on and on about this, but I already put it down here: http://www.zathras.de/angelweb/blog-so-when-will-it-be-more-secure.htm
Posted by: Peter da Silva at January 23, 2006 01:05 PM
I think Apple has made some real mistakes. Auto-installing Dashboard widgets is stupid (albeit about 4 levels of stupidity below ActiveX and IE), and "Open Safe Files After Downloading" is a silly name for "Open Potentially Unsafe Files After Downloading"... but at least you can turn it off.
I've got some comments in my not-a-blog about it:
http://www.scarydevil.com/~peter/io/osx-security.html
http://www.scarydevil.com/~peter/io/apple.html
http://www.scarydevil.com/~peter/io/apple2.html
Posted by: Matt at January 26, 2006 10:26 AM
I'm not so sure about Apple's developers having security at the front of their (collective) minds.
As recently as 10.4 they've had setuid root apps trusting environment variables - search for 'getenv("USER")' at http://darwinsource.opendarwin.org/10.4/DSTools-60/dsidentity/dsidentity.cpp and have yourself a chuckle... There're also similar issues with malloc debug env vars, I wouldn't be surprised if there are various other design issues lurking.
Posted by: Wes McGee at January 26, 2006 11:45 AM
Funny how this article should come up on MacSurfer today...
Posted by: Anthony at January 26, 2006 12:56 PM
As recently as 10.4 they've had setuid root apps trusting environment variables - search for 'getenv("USER")'Oh dear god. That's worthy of Microsoft.
Posted by: Peter da Silva at January 27, 2006 01:34 PM
Nah, Microsoft wouldn't have fixed it so fast, and nobody would have cared because nobody's worried about new privilege elevation attacks on Windows when most users run with Administrator privileges all the time anyway.
Worthy of SGI, maybe? Or SCO. I can't decide which of the two would be more likely to have this kind of thing. Or maybe HP... nah, HP-UX is so old it's probably still got V6 code in there, and V6 didn't have getenv.
The worst I've seen was a script that checked $PS1 to see if it contained a "#". :)
Posted by: Anthony at January 27, 2006 04:48 PM
Microsoft wouldn't have fixed it so fastMicrosoft would have designed the OS so it couldn't be fixed. :)
I've noticed that they have a non-executable stack even though they have to drop features to make it work. It's good to see a major vendor pick security over expediency. Unlike many Mac users, Apple appears to be actively working to improve/maintain security.
Non-executable stacks don't stop buffer overflow attacks, but they certainly do help. x86 chips that support the per-page execute bit allow for much tighter grained security than that, and there's a number of other techniques pioneered by OpenBSD and others. Hopefully OS X will inherit some of the ideas.