Mac OS X malware "OSX/Oomp-A" discovered -- effects seem innocuous
Andrew Welch of Ambrosia Software has discovered and described a new piece of malware for Mac OS X dubbed the "Oompa-Loompa Trojan (OSX/Oomp-A)"
The malware was posted as "latestpics.tgz" to a Mac rumors web site, claiming to be pictures of "Mac OS X Leopard" (an upcoming version of Mac OS X.
Andrew writes:
"When unarchived (it is a gzip-compressed tar file), which can be done by simply double-clicking on the file, it appears to be a JPEG file because someone pasted the image of a JPEG file onto the file.
"After it's been unzipped, tar will tell you there are two files in the archive:
- ._latestpics
- latestpics
"The ._latestpics is just the resource fork of the file, which contains the pasted in custom icon meant to fool people into double-clicking on it to (in theory) open the JPEG file for viewing. In actuality, double-clicking on it will launch an executable file.
"The file 'latestpics' is actually a PowerPC-compiled executable program, with routines such as:
- _infect:
- _infectApps:
- _installHooks:
- _copySelf:
- This should probably be classified as a Trojan, not a virus, because it doesn't self-propagate externally
- It does not exploit any security holes; rather it uses "social engineering" to get the user to launch it on their system
- It requires the admin password if you're not running as an admin user
- It doesn't actually do anything other than attempt to propagate itself via iChat
- It has a bug in the code that prevents it from working as intended, and has the side-effect of preventing infected applications from launching
- It's not particularly sophisticated
- It copies itself to /tmp as "latestpics"
- It recreates its resource fork in /tmp (with the custom icon in it) from an internally stored gzip'd copy, then sets custom icon bit for the new file in /tmp
- It then tar gzips itself so a pristine copy of itself in .tgz format is left in /tmp
- It renames itself from "latestpics.tar.gz" to "latestpics.tgz" then deletes the copied "latestpics" executable from /tmp (This gives it a pristine copy of itself, for later transmission)
- It extracts an Input Manager called "apphook.bundle" that is embedded in the macho executable, and copies it to /tmp
- If your uid = 0 (you're root), it creates /Library/InputManagers/ , deletes any existing "apphook" bundle in that folder, and copies "apphook" from /tmp to that folder; If your uid != 0 (you're not root), it creates ~/Library/InputManagers/ , deletes any existing "apphook" bundle in that folder, and copies "apphook" from /tmp to that folder
- When any application is launched, Mac OS X loads the newly installed "apphook" Input Manager automatically into its address space (This allows it to have the code in the "apphook.bundle" injected into any subsequently launched application via the InputManager mechanism)
- When an application is subsequently launched, the "apphook.bundle" Input Manager then appears to try to send the pristine "latestpics.tgz" file in /tmp to people on your buddy list via iChat (who will then presumably download the file, double-click on it, and the cycle repeats) (It looks like the author intended to get it to send the "latestpics.tgz" file out via eMail as well, but never got around to writing that code) -- This lets it send itself to people on your buddy list via iChat; this appears to be the only way it self-propagates externally
- It then uses Spotlight to find the 4 most recently used applications on your machine that are not owned by root
- In an apparent "Charlie and the Chocolate Factory" reference, it then checks to see if the xattr 'oompa' of the application executable is > 0... if so, it bails out, to prevent it from re-infecting an already infected application
- If not, it sets the xattr 'oompa' of the application executable to be 'loompa' (this does nothing, it is just a marker that it has infected this app)
- It then copies the application executable to its own resource fork, and replaces the executable with itself -- It has thus effectively injected its code in the host application
- When an application is launched from then on, the trojan code is executed, and it tries to re-infect and re-propagate every time that application is launched
- It then does an execv on the resource fork of the executable, which is the original application, so the application launches as it normally would (in theory... see below)
"In the end, it doesn't appear to actually do anything other than try to propagate itself via iChat, and unintentionally prevent infected applications from running
"It seems that this is more of a 'proof of concept' implementation that could be utilized to actually do something in the future, depending on how successful it is, or it was simply done to garner attention/press. Which I'm sure it'll get.
As noted by Andrew, this particular piece of malware requires user-initiated action to run, and also requires the user to enter an administrator password (if you are logged in as a non-admin user) -- something that should never be required for opening a .jpg file. Its effects also seem to be innocuous.
Feedback? Late-breakers@macfixit.com.
Resources

"?this particular piece of malware requires user-initiated action to run, and also requires the user to enter an administrator password -- something that should never be required for opening a .jpg file."
As has been shown many times before, just because a piece of malware requires user interaction, or has odd characteristics which more knowledgeable Mac users would be wary of, doesn't mean it won't be "successful" malware--"unaware" Windows users often open attachments to their email which are actually viruses, trojans, etc., and they sometimes also download "interesting" items like the malware being described here, and open them. From my experience, there may be little if any greater degree of sophistication among many Mac users--many will probably just go ahead and enter their password when asked.
"Its effects also seem to be innocuous."
I wouldn't say that not being able to open infected applications is innocuous, even if this is an "unintentional" result of the malware's actions.
Isn't it a problem to publish virus source code on the Web?
Someone might now copy and paste the published code and assemble it to make a new threat.
No need to enter admin password here.
One more thing: that's not a programmer's bug, but imho rather intended. Applications are infected in both forks. Think again.
The apphook InputManager is a worm. It spreads itself with hidden features(not revealed for now). Read again.
for your
password to open a jpeg? Even the most novice user will think something is
fishy. And even then it cannot propagate itself. I think MacFixit should
absolutely stand by its term "innocuous" and save "dangerous" for something
that will actually effect more than .00000000001 percent of Mac
users.<br><br> Of course, I'm sure the other media will jump up and down
in hysterics once they get ahold of this story, so you'll be sure to see the term
"dangerous", "critical" etc. through those channels. Hahaha...<br><br>
""? johnsawyercjs, did you miss the part where it will ask you
for your password to open a jpeg? Even the most novice user will think
something is fishy.""
Oh Cowicide, how little you know about the novice user.
From what I've seen, working with thousands of Mac users since 1985, even many not-so-novice users (let alone "the most novice user", who by definition knows nothing about security precautions) will think nothing of it when asked to enter their admin password to open a jpeg. The only saving situation here is that many of these people won't know what their admin password is--I have a fair number of clients running OS X who don't know. I don't know how they manage to install software, run utilities, etc. if they don't know their own admin password, but it seems someone else does that for them.
As for not propagating itself, the article isn't clear about that--it says it "tries" to propagate itself via iChat, but doesn't say if it's successful or unsuccessful at doing this. One should assume it might be successful at least part of the time. The damage it seems to be able to do on the Mac it's launched on, to applications it infects, sounds bad enough.
You're right when you say this particular malware will affect practically no Mac users, but it seems fair to discuss it since a "better-written" version might do more harm at some point in the future.
The part that gets me is that if you're logged into an admin account, which most OS X users are, you're usually not even asked for an admin password for this thing to run.
So am I correct in inferring that if I open this while logged in as an adminitrator, I will get no warning that something is being installed on my computer? Why wouldn't it ask me for my password if it's installing something on my computer?
account as you already have read/write access to the folder it installs into and
executes from (InputManagers don't need a password to be installed, but
Apple may very well change this in future updates now... Hahaha)
...and THAT change may be EXACTLY what the "author" was looking for. That plus the attention of the media, both internet-based and TV/Radio/Print-based, to feed his or her fragile ego. ("Wow, look at what I made Apple do...I'm a big wheel!")
As a programmer by trade, I find it ironic that it was (apparently) a flaw in the code that causes the real damage associated with this particular Trojan. Some people just can't code their way out of a wet paper bag...
unintentional infection.
any further clues?
- by pupspals February 20, 2006 3:00 PM PST
- So.... If it uses Spotlight...
- Like this Reply to this comment
-
(10 Comments)If you're running 10.3.9 or earlier are you ok???