"Rosetta" applications suddenly stopped working

X423424X wrote:

Ok, assuming the environment.plist was there and you did my most recent mv to rename it to environment.old.plist then try this:

sudo defaults read environment.old

That will display all definitions in that file.

Assuming you have already did cd ~/.MacOSX/

Or to be sure:

sudo defaults read ~/.MacOSX/environment.old

sudo probably not necessary, but it doesn't hurt. And any text editor will be able to read it, as well as QuickLook.

As others have said, environment.plist is not a preference and by my guess won't be found on 99% of Macs. I added it to mine just to try out a new prefs panel I came across. I've found one other user here who had one added by an application, but I'm guessing the installer put it there, so if it's needed and not corrupt it probably needs to be restored. I'm sure the system won't restore it and the application that needs it probaby won't either.

Assuming you have already did cd ~/.MacOSX/

Oops! I think this thread is wearing me out (or down). Sorry about that.

sudo probably not necessary, but it doesn't hurt. And any text editor will be able to read it, as well as QuickLook.

I was avoiding adding more details to this just in case for some weird unknown reason it got created as a binary plist. Then I would have to go back and explain that in yet another post.

That is what I have found on my 3.06 GHz Intel Core 2 Duo - 10.6.8 MAC.

I have been trying to open:

Freehand MX

Microsoft Office

Excel

PowerPoint

Entourage

Reason of conflict(nothing opens): infected by:

http://www.f-secure.com/v-descs/trojan-downloader_osx_flashback_i.shtml

Matt

X423424X wrote:

sudo mv ~/.MacOSX/environment.plist ~/.MacOSX/environment.plist.old

[…]

sudo defaults read environment.old

If the mv was executed as described, this command will not work. Defaults will attempt to read environment.old.plist, not environment.plist.old.

I suggest

less ~/.MacOSX/environment.plist.old

Also, I suggest looking at the latest posts in

Freehand not opening - Rosetta installed?

He didn't quote me directly or correctly. My post had it correct,

sudo mv ~/.MacOSX/environment.plist.old ~/.MacOSX/environment.old.plist

And as I said above I was just trying to avoid the remote possibility it was a binary plist and having to explain it, which now, by this point, I've had to explain twice.

And now, if he will actually print the thing already, any which way, we can stop screwing around with syntax or how to do it. Enough already.

X423424X wrote:

He didn't quote me directly or correctly.

Sorry, X423424X, I'm afraid this thread is too dense and I wasn't able to follow it closely. As long the file name extension is .plist, defaults will read the file. I'm not quite sure at this point what it is on the OP's machine. Perhaps

less ~/.MacOSX/enviro*

will take care of all possibilities.

NuLynx wrote:

As I said, my computer is VERY rarely online. We are blocked by a strict firewall that blocks most everywhere we try to go. So, unless the trojan can be picked up by a PC (up in the front of the company), transferred throughout the internal network, and infecting my computer, but nobody else's.....which I won't rule out, but..Occam's Razor and all that...probably not likely. Still, I throw out my appology on the chance that it could be the case. Just too many forums where it ends up being "But, that's not what I was talking about in the first place...now you own it."

Although this malware gang is targeting PC's with a similar Trojan using much the same approach, I don't see how one set of code could possibly migrate effectively from PC to Mac.

However, if it was online at all, it could have been infected in seconds simply by visiting one of the poisoned WordPress blog sites I mentioned earlier. It enters as a rendered Java applet directly into RAM via any browser on port 80, which I'm sure your firewall is not blocking. If Java is not up-to-date, then it's free to use one of two Java exploits to do most anything it wants to. Otherwise, it just installs a temp file and attempts installation. If they can trick the user into approving something (last two were an untrusted fake Apple certificate and a request for admin password from a fake Software Update dialog). If they get admin status then they install the code directly into one or more browsers and other network applications (Skype being the only one verified by Intego).

If they do not obtain Admin status it checks for the presence of:

• /Applications/Microsoft Word.app
• /Applications/Microsoft Office 2008
• /Applications/Microsoft Office 2011
• /Applications/Skype.app

If any of these are found, the malware skips the rest of its routine and proceeds to delete itself, presumably to avoid infecting a system that has an incompatible application installed.

Otherwise, it installs the afore mentioned environment.plist and the code gets tucked away in the user area (either /Users/Shared/ or ~/Library/Applications Support/) as invisible files. The second type is what happend to the other users who convirmed infection earlier today. The interesting thing about the latter type is that it does not inject code onto the hard drive, so the applications themselves remain clean. It's only after they are launched that the additional code is added. Most applications will run just fine with this added code which won't do anything if it's not a targetted network app.

A full installation consists of a backdoor that can be used to update the malware remotely and the code necessary to both redirect browsing periodically and to capture UserId/Password combination and using Twitter, send whatever information it has back to the C&C server. The backdoor checks with that same C&C server periodically for instructions.

Since you do not have an environment.plist with a DYLD_INSERT_LIBRARIES entry, then I don't think you are infected by Flashback A, G, or I type 2. You could still have Flashback B, C, N, I type 1 or one of the ones we have no information about (D, E, F, H, J, K, L, M,...). If my theory that Intel code injection is what's causing your issue, I believe that only the most recent variants use that technique.

Admittedly, it's very strange that removing environment.plist solved your issue without it being infected, especially since we seem to have others with the same identical problem who confirmed infection.

Unfortunately, this Trojan is not a case of "only" that Trojan," and I think it would be premature to consider this thread at an end. The original problem is solved, but depending on the variant, this crap may be installed in any number of possible places. I don't think simply deleting that one file will remove the entire infection. But I'll let Mad or X4 help you out with what needs to be done now.

{

"DYLD_INSERT_LIBRARIES" = "/Users/Shared/.libgmalloc.dylib";

}

Finally! 🙂 We can put to reset whether it was or was not the trojan. And I think Flashback.I. I'll defer to MadMacs0 to complete this but at the very least, with the environment.plist removed the trojan is disabled. But as implied by that plist it is not the only file that was installed on the system. This is why I wanted that plist shown. It indicates that /Users/Shared/.libgmalloc.dylib is a specific chunk of code used by other trojan code. So to remove at least this file, again in terminal, copy/paste the following line:

rm -rf /Users/Shared/.libgmalloc.dylib

There still remains the code that is using this dylib. The Flashback.I info talks about this being embedded in Safari. If so it might be easier to just download a fresh copy of Safari. At any rate, to say again, the trojan is effectively disabled with the plist (and dylib) removed.

NuLynx wrote:

few questions before we close this thread...

Can this thing be spread through e-mail at all? (Just trying to figure out if it was possible to get it from a client that was infected), or along those same lines, this all started while working on a large problem file (with all of the font conflicts)...is there any way this trojan can be attached to a file and spread to others?

That has not been reported by anyone. Internet access is a key componenet of it's operation and it starts as an embedded Java applet which had only been found on web pages. I see no reason that it couldn't be mailed to a user, but that's a long shot.

Second question...X423424X gave me the terminal command to get rid of the environment.plist...

In doing so, does that take care of this little beastie once and for all?

That's not a safe bet. It seems to get rid of the code injection, but we don't know if it shuts down the backdoor or communications with the Mother Ship.

So here's the standard advise from several of us:

Since we do not have complete information about everything this Trojan is capable of and the location of everything it installs, the advise of most of us has been to make sure you have all your data files backed up and using your installation disks, format your hard drive, install a clean, fully updated OS X and all applications from source, then restore only your data files from backup.

Another choice, if you have a TimeMachine backup would be to determine when you were infected and restore your hard drive to the condition it was in just prior to the infection.

Lastly you can choose to take a chance and remove the files we know about which should remove all the obvious problems you have discovered, but may not completely disable all of the Trojan's functions.

A couple of questions for you. Are you able to view invisible files? There are Terminal commands available to remove these files, but it's always best to be able to confirm that they are there to start with and that they are gone after issuing the commands.

It would help to know the date of infection. One of the other users found out by double-clicking one of the files and having a quarantine warning pop-up (which is the first confirmation that quarantine even works with this variant), but that's not the safest method. If you are able to locate these files, do a "Get Info" to determine the creation date should tell us that, although it's not foolproof. Your findings so far have narrowed this down to one of two or three variants. Knowing the infection date will help pick which one.

If it's the same one the other users in this thread found and you are unwilling or unable to erase and restore, then the best guidance available is to follow the "Manual Removal Instructions" in the document I previously mentioned: http://www.f-secure.com/v-descs/trojan-downloader_osx_flashback_i.shtml. If this doesn't work then you may have an older, newer or undocumented variant.

No matter which choice you make you will need to change some passwords as the Trojan has almost certainly already harvested some of your username/password pairs and used Twitter to send them to the bad guys.

There still remains the code that is using this dylib. The Flashback.I info talks about this being embedded in Safari. If so it might be easier to just download a fresh copy of Safari.

That won't hurt, but is only applicable to the Type 1 version which does not use the environment.plist, so he's either got Type 2 or some variant other than "I".

At any rate, to say again, the trojan is effectively disabled with the plist (and dylib) removed.

We think. There's still the matter of the backdoor and communicating back to the Mother Ship. Are these functions contained in the dylib or somewhere else?

This is why I deferred to you to on this insidious stuff. 😉

And if that wasn't enough:

http://www.infoworld.com/d/security/mac-malware-exploits-microsoft-office-vulner ability-189821

AlienVault believes that this attack was carried out by the same gang that last week distributed a similar Mac Trojan by exploiting a vulnerability in outdated Java installations.

Yes I read about this a couple of nights ago. Same exploit, but I believe it's a different gang in China targeting Tibet via e-mail links. This showed up yesterday as ESET decided to install it and see what happened: http://blog.eset.com/2012/03/28/osxlamadai-a-the-mac-payload . They ended up watching what appears to be a live operator hunting for Keychains and cookies, then uploading them. An obvious identity theft situation.