Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Could it be that Mac Users have been grossly mislead by Apple?

Here's a few different writers take on it.

Apple malware flourishes in a culture of denial
http://is.gd/d0u7d6

Security industry insiders have long known the Mac platform has its holes. The Flashback Trojan is the first in-the-wild issue that's confirmed this, and big-time. More will follow unless Apple steps up its game.
http://is.gd/LSRB7a

All right, Mac users — the day of reckoning has come.
Thanks to a well-documented flaw that Apple didn't patch for three months, a nasty piece of malware called Mac Flashback seems to have infected nearly 600,000 Macs worldwide
http://is.gd/rG3gnx

Flashback Trojan dates back to February, but Apple did not release a patch until April 3. As a result, approximately 550,000 Macs were infected
http://is.gd/tiU1Td

Sorokin noted that 274 of the infected Macs were found in Cupertino, Calif., where Apple keeps its headquarters.
http://is.gd/0FzBvD

Have you been put off by the work required to see if your machine is one of the unlucky ones infected with a Trojan that's been making the rounds?
http://is.gd/Da0zWn

Obligatory counterargument.

1) Until Vista, the admin account in Windows did not implement DAC in a way to prevent malware by default. Also, Windows has a far greater number of privilege escalation vulnerabilities that allow bypassing DAC restrictions even if DAC is enabled in Windows.

Much of the ability to turn these vulnerabilities into exploits is due to the insecurity of the Windows registry. Also, more easily being able to link remote exploits to local privilege escalation exploits in Windows is due to the Windows registry.

Mac OS X does not use an exposed monolithic structure, such as the Windows registry, to store system settings. Also, exposed configuration files in OS X do not exert as much influence over associated processes as the registry does in Windows.

Mac OS X Snow Leopard has contained only 4 elevation of privilege vulnerabilities since it was released; obviously, none of these were used in malware. Lion has contained 2 so far but one of these vulnerabilities doesn't affect all account types because of being due to a permissions error rather than code vulnerability.

The following link shows the number of privilege escalation vulnerabilities in Windows 7 related to just win32k:

http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=win32k+7

More information about privilege escalation in Windows 7:

http://www.exploit-db.com/bypassing-uac-with-user-privilege-under-windows-vista7-mirror/ -> guide to develop exploits to bypass UAC by manipulating registry entries for kernel mode driver vulnerabilities.

https://media.blackhat.com/bh-dc-11/Mandt/BlackHat_DC_2011_Mandt_kernelpool-wp.pdf -> more complete documentation about Windows kernel exploitation.

http://mista.nu/research/mandt-win32k-paper.pdf -> more complete documentation about alternative methods to exploit the Windows kernel.

http://threatpost.com/en_us/blogs/tdl4-rootkit-now-using-stuxnet-bug-120710 -> article about the TDL-4 botnet which uses a UAC bypass exploit when infecting Windows 7.

2) Windows has the potential to have full ASLR but most software does not fully implement the feature. Most software in Windows has some DLLs (dynamic link libraries = Windows equivalent to dyld) which are not randomized.

http://secunia.com/gfx/pdf/DEP_ASLR_2010_paper.pdf -> article overviewing the issues with ASLR and DEP implementation in Windows.

Also, methods have been found to bypass ASLR in Windows 7.

http://vreugdenhilresearch.nl/Pwn2Own-2010-Windows7-InternetExplorer8.pdf -> article describing bypassing ASLR in Windows 7.

Mac OS X has full ASLR implemented on par with Linux. This includes ASLR with position independent executables (PIE). DLLs in Windows have to be pre-mapped at fixed addresses to avoid conflicts so full PIE is not possible with ASLR in Windows.

Using Linux distros with similar runtime security mitigations as Lion for a model, client-side exploitation is incredibly difficult without some pre-established local access. Of course, this is self defeating if the goal of the exploitation is to achieve that local access in the first place.

See the paper linked below about bypassing the runtime security mitigations in Linux for more details.

http://www.blackhat.com/presentatio...Europe-2009-Fritsch-Bypassing-aslr-slides.pdf

The author only manages to do so while already having local access to the OS.

3) Mac OS X Lion has DEP on stack and heap for both 64-bit and 32-bit processes. Third party software that is 32-bit may lack this feature until recompiled in Xcode 4 within Lion. Not much software for OS X is still 32-bit.

But, not all software in Windows uses DEP; this includes 64-bit software. See first article linked in #2.

4) Mac OS X implements canaries using ProPolice, the same mitigation used in Linux. ProPolice is considered the most thorough implementation of canaries. It is known to be much more effective than the similar system used in Windows.

http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-silberman/bh-us-04-silberman-paper.pdf -> article comparing ProPolice to stack canary implementation in Windows.

5) Application sandboxing and mandatory access controls (MAC) in OS X are the same thing. More specifically, applications are sandboxed in OS X via MAC. Mac OS X uses the TrustedBSD MAC framework, which is a derivative of MAC from SE-Linux. This system is mandatory because it does not rely on inherited permissions. Both mandatorily exposed services (mDNSresponder, netbios...) and many client-side apps (Safari, Preview, TextEdit…) are sandboxed in Lion.

Windows does not have MAC. The system that provides sandboxing in Windows, called mandatory integrity controls (MIC), does not function like MAC because it is not actually mandatory. MIC functions based on inherited permissions so it is essentially an extension of DAC (see #1). If UAC is set with less restrictions or disabled in Windows, then MIC has less restrictions or is disabled.

http://www.exploit-db.com/download_pdf/16031 -> article about Mac sandbox.

http://msdn.microsoft.com/en-us/library/bb648648(v=VS.85).aspx -> MS documentation about MIC.

https://media.blackhat.com/bh-eu-11/Tom_Keetch/BlackHat_EU_2011_Keetch_Sandboxes-Slides.pdf -> researchers have found the MIC in IE is not a security boundary.

6) In relation to DAC and interprocess sandboxing in OS X in comparison with some functionality of MIC in Windows 7 (see #5), the XNU kernel used in OS X has always had more secure interprocess communication (IPC) since the initial release of OS X.

Mac OS X, via being based on Mach and BSD (UNIX foundation), facilitates IPC using mach messages secured using port rights that implement a measure of access controls on that communication. These access controls applied to IPC make it more difficult to migrate injected code from one process to another.

Adding difficulty to transporting injected code across processes reduces the likelihood of linking remote exploits to local exploits to achieve system level access.

As of OS X Lion, the XPC service has also been added to implement MAC (see #5) on IPC in OS X. (http://developer.apple.com/library/...stemStartup/Chapters/CreatingXPCServices.html)

7) Windows has far more public and/or unpatched vulnerabilities than OS X.

http://www.vupen.com/english/zerodays/ -> list of public 0days.

http://www.eeye.com/Resources/Security-Center/Research/Zero-Day-Tracker -> another list of public 0days. (Most if not all of the Apple vulnerabilities in this list were patched in the latest Apple security update -> http://support.apple.com/kb/HT5002)

http://m.prnewswire.com/news-releas...-vulnerability-in-microsoft-os-110606584.html -> article about 18 year old UAC bypass vulnerability.

8) Password handling in OS X is much more secure than Windows.

The default account created in Windows does not require a password. The protected storage API in Windows incorporates the users password into the encryption key for items located in protected storage. If no password is set, then the encryption algorithm used is not as strong. Also, no access controls are applied to items within protected storage.

In Mac OS X, the system prompts the user to define a password at setup. This password is incorporated into the encryption keys for items stored in keychain. Access controls are implemented for items within keychain.

Also, Mac OS X Lion uses a salted SHA512 hash, which is still considered cryptographically secure. It is more robust than the MD4 NTLMv2 hash used to store passwords in Windows 7.

http://www.windowsecurity.com/articles/How-Cracked-Windows-Password-Part1.html -> article about Windows password hashing.

9) The new runtime security mitigation improvements to be included in Windows 8 have already been defeated.

http://vulnfactory.org/blog/2011/09/21/defeating-windows-8-rop-mitigation/

To put this into perspective, methods to bypass the new runtime security mitigations in Mac OS X Lion are not yet available.

10)In regards to recent earlier version of Mac OS X:

The following image relates to varying levels of security mitigations in different Linux distros but it is applicable in revealing that the runtime security mitigations in some earlier versions of Mac OS X prior to Lion were far from inadequate.

NX.png

source -> http://www.blackhat.com/presentatio...Europe-2009-Fritsch-Bypassing-aslr-slides.pdf

The following section of that image represents a comparison of Mac OS X Leopard/Snow Leopard to Windows Vista/7.

NXsmall.png

While Mac OS X Leopard/SL lack full ASLR, Windows Vista/7 have stack canaries (aka stack cookies) that are trivial to bypass.

The following link shows the issues with stack canaries in Windows. -> http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-silberman/bh-us-04-silberman-paper.pdf

So:

Windows Vista/7 = NX + ASLR
Mac OS X Leopard/SL = NX + stack cookies

NXsmall.png

The image shows that NX in combination with stack canaries is more difficult to bypass than a combination of NX and ASLR.

This Java exploit doesn't bypass the new runtime security mitigations in OS X Lion so #9 is still valid.

Multiple vulnerabilities exist in Java 1.6.0_29, the most serious of which may allow an untrusted Java applet to execute arbitrary code outside the Java sandbox. Visiting a web page containing a maliciously crafted untrusted Java applet may lead to arbitrary code execution with the privileges of the current user.

http://support.apple.com/kb/HT5228

But, it has the capacity to bypass Java's sandbox, which indicates an issue existed with that sandbox configuration that didn't manifest in other apps.

Also, the user had to accept the self signed certificate for the Java applet prior to any infection occurring so user interaction was required before any infection occurred.

Successful infection required the user to also password authenticate the installation so that Safari could be infected given that the target of the payload was Safari.

Without password authentication, that payload only infected apps owned by the user which it was not meant to infect so the apps functions were not modified.
 
I don't see him/her mention windows anywhere.

The post mentions the security industry.

The security industry chronically over sells the security of Windows and under sells the security of OS X.

This is due to Microsoft being a major sponsor of most security conferences and etc while Apple doesn't provide any funding to that community.

This is form of what is called funding bias in relation to research. It happens all the time.
 
Flashback

ok here's a hypothetical. Suppose this flashback does enter a mac. Then apple fixes the hole with their new Java update. Will the system recognize the trojan and kick it out? will it notify the user?
 
ok here's a hypothetical. Suppose this flashback does enter a mac. Then apple fixes the hole with their new Java update. Will the system recognize the trojan and kick it out? will it notify the user?
No, a Java update won't remove malware. The removal instructions have been posted repeatedly in this thread and others.
 
The post mentions the security industry.

The security industry chronically over sells the security of Windows and under sells the security of OS X.

This is due to Microsoft being a major sponsor of most security conferences and etc while Apple doesn't provide any funding to that community.

This is form of what is called funding bias in relation to research. It happens all the time.

Ok I see why you posted that info, I just don't understand why it always ends up in a Mac/Windows thing. If there's a vulnerability in OSX i personally don't care about windows having the greater percentage of infections i just want the hole patched and lets move on. I personally never had anything infect my Windows PC in 10 years bcuz my AV always caught it and either quarantined or removed it. Would all the Mac users suddenly abandon Apple if they were required AV to keep their Macs uninfected?
 
Doubtful, since they didn't when that was required with Mac OS 9 and earlier.

Thank you! I have a Windows PC that I still use from time to time( Mostly the kids use it though ) I have no problems with it but as soon as it goes down that will be the last Pc that I'll own unless something extraordinary happens and I'm REQUIRED to purchase another . I prefer a Mac bcuz I can operate it just a little easier than a PC, it looks better and things are easier for me to find. I already run Lil Snitch which though it is not technically an AV programs I view it as one. I don't need the newest thing as soon as it comes out so I just use it til it breaks. Anyway if anyone was under the impression that Macs will NEVER get virus,malware,etc...they really need to be better informed.
 
I've used both Macs & Windows computers concurrently, for many years.

Not once have I experienced a virus or malware on any of my Windows PC's or Mac's until the present.

In the case of my Windows machines, I've taken the needed measures to stay educated, and kept them protected with the requisite software to prevent such threats from gaining access.

My MacBook Pro checked out positive and was a victim to Flashback. Why?

Because I failed to do my job properly. I became complacent, it's as simple as that. Welcome to the world of computing.

I allowed myself to become complacent since I've used Macs for so long, without thinking of viruses or malware, that I just didn't stay up with the changes that happen over time. Therefore as mentioned earlier this was my fault. No computer is perfect. I don't care what platform it is.

Once I tested my MBP & found the presence of Flashback, I followed the instructions for removal via command line, and soon I was up & running no problem. Yet I should mention I'm quite familiar with the terminal as I use it regularly. For those who do not, the task will require more time & patience.

At the end of the day, I've enjoyed so many years of smooth and fast running Macs, this was no big deal.

I still prefer Mac, hands down.
 
I may have missed it but I will ask anyway.

1. Is this malware the first one to not require any user interaction at all on OSX? From what I read it just installs itself and is considered a drive by download through an exploit in Java.

2. What exactly is the payload? I am guessing it gets passwords and such?

3. Removal for the less tech savvy. All of us here could easily remove it by following instructions, but what about the less techie people how will they get rid of it? Will it be added to the OS on the protect list or whatever?

4. Last one. If OSX malware gets this much publicity, where does one find how much comes out for windows or Linux. I would guess Windows has a larger amount written for it, yet I never see many articles on it.

Just curious, I am somewhat decent at security, I have Java disabled, and flash is click to flash on my machine. My Win machine never touches the net since its more for encoding videos.
 
If you have Java disabled and you didn't install anything, you don't have this trojan.

Yeah I read that part but was simply curious about the other questions. Javascript is safe correct? Obviously I can't hardly use the net without it. Pardon the noob in me LOL
 
Yeah I read that part but was simply curious about the other questions. Javascript is safe correct? Obviously I can't hardly use the net without it. Pardon the noob in me LOL
Yes, JavaScript is fine. Read the article and links at the beginning of this thread, as well as the dozens of links throughout this thread for details about this trojan, including payload, detection, removal, etc.
 
Yes, JavaScript is fine. Read the article and links at the beginning of this thread, as well as the dozens of links throughout this thread for details about this trojan, including payload, detection, removal, etc.

Gotcha, I will set aside some time for that. Never hurts to learn more.

Thanks !!
 
Logged in as admin on Leopard, it does not prompt for a password. It does on Snow Leopard (and I assume Lion).

As I said earlier, it appears to depend on which OS version you're running.

No, it doesn't. It would appear that something is wrong with the permissions of /Applications on your system. On both 10.6 and 10.7 an admin account has write privileges for /Applications; there's no reason you should be getting an authentication dialog when trying to write to it from such--only from a user account.
 
No, it doesn't. It would appear that something is wrong with the permissions of /Applications on your system. On both 10.6 and 10.7 an admin account has write privileges for /Applications; there's no reason you should be getting an authentication dialog when trying to write to it from such--only from a user account.
It was already confirmed by others that they also get a prompt for admin password on SL and Lion. There is nothing wrong with my permissions.
 
It was already confirmed by others that they also get a prompt for admin password on SL and Lion. There is nothing wrong with my permissions.

No it wasn't confirmed by others; the two people who followed your steps never identified what type of account they were using--only that they had to authenticate.
 
No it wasn't confirmed by others; the two people who followed your steps never identified what type of account they were using--only that they had to authenticate.
I haven't tested it on Lion, but logged in as an admin user on Leopard, it doesn't ask for a password. On multiple Macs running Snow Leopard, it does.
 
No it wasn't confirmed by others; the two people who followed your steps never identified what type of account they were using--only that they had to authenticate.

Well I get a prompt to authenticate and I am the Admin for the Mac. Running 10.7.3
 
I haven't tested it on Lion, but logged in as an admin user on Leopard, it doesn't ask for a password. On multiple Macs running Snow Leopard, it does.

This is not standard, out-of-the-box behaviour for either 10.6 or 10.7. The whole point of a user or group having write permissions is so they can freely write to a directory without the need to authenticate.

On my 10.6.8 machine I just changed /Applications to "write only" for the admin group:
Faulty Permissions.png

Running Verify Disk Permissions in Disk Utility gives the following:
Repair Permissions.png

The default permissions for the /Applications folder in 10.6.8 do not require an admin to authenticate writing to that directory. I don't know what you have going on, but it's not default behaviour. Perhaps an installer changed the permissions of your /Applications folder (this happens from time to time).

(I've also run the same test on one of my 10.7.3 machines--which was a fresh install of Lion just yesterday. Disk Utility reports the same. On all of my home machines, no matter the system version, I can write to /Applications as an admin; this is the expected behaviour.)
 
Last edited:
That wasn't what was being tested. Read my earlier posts to see the steps involved.
:eek:
I've followed the whole thread and I did in fact read your first post on the subject. That said, I don't know how it got into my head that you were referring to the folder itself--and then I got the discussion completely derailed.

Pardon me while I slink away, hoping nobody noticed :cool:
 
Well written AV programs update themselves.
They take the user out of the equation.
I have yet to see a REAL AV program get compromised.
By real I mean programs like McAfee, not the freeware AV programs.

I've seen them get disabled do to holes in the OS about 10 years ago, but never compromised directly.

Well I have one for you. Last year my dad was running two XP comps at different locations with Mcafee on both. Both had the latest service packs and updates to both Mcafee and the system. Then one machine got a trojan that made itself look like he needed an update, like Microsoft was asking for $80 to get the latest security program or else the system wouldn't work. Then his other comp got the same thing the next day. Long story short my dad lost money for having two comps down and had to pay a tech guy more money to remove those nasty little apps. I was left to back up, wipe the drives, and reinstall everything.
Mcafee never even seen the malware after several searches. It was $80 a year for nothing. I am trying to get his next purchase to be a Mac, but he needs one app that is Windows only.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.