Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
For all intents and purposes, the distinction between "trojan" and "virus" is irrelevant. It's still malware, and the most common infection vector these days is via the browser. There are and will continue to be HTML rendering engine exploits.

Yes, safari and chrome are sandboxed, but the mac has been owned every year at pwn2own so far, and I don't see that changing any time soon.

The Java exploit used in Flashback didn't rely on memory corruption but utilized a logical error related to the reference array in Java. In general, this type of vulnerability is rare but seems to be more prevalent in relation to Java.

HTML rendering exploits rely on memory corruption. Currently, there are no known methods to bypass the runtime security mitigations in Lion and ML to allow these types of vulnerabilities to be exploited.

For example, Safari running on Lion was not compromised at the last pwn2own.

re: av subversion.

read my post. its not a silver bullet. it is an additional layer. trusting your security to a single layer (safe computing) is negligent. accidents happen. are you really sure that you will NEVER click on something dodgy, at 2am after a few pints?

Read my post. OS X includes AV software by default so it already has multi layer defenses.
 
I agree that safe computing practices can keep you safe.

But, this variant of Flashback does meet the definitional requirements to be a virus.

It requires no user interaction and it replicates.

I think the argument for it being defined as a virus is further supported by the fact that it required no user interaction on many default installations of OS X.

I had not really looked at Flashback in this way, but you are absolutely correct that it meets the definition of a virus.
 
I had not really looked at Flashback in this way, but you are absolutely correct that it meets the definition of a virus.

Given that only 10,000 machines were actively generating revenue for the malware developers, this version of Flashback was still relatively unsuccessful.

Combined with the fact that the vector used to inject payloads into apps without password authentication has been removed from OS X, the low revenue generated by this malware isn't a big motivator for the development of more malware like Flashback.
 
To clarify on how the Flashback Java exploit works to achieve remote code execution:

Java applets already have the ability to be executed; that is the purpose of the applet.

Unsigned or self-signed applets have access limitations applied to the applet given that these types of applets are often used in malware. The access limitations are set by the Java sandbox.

The exploit only has to bypass the sandbox access limitations because Java, given its inherent purpose, already has the capacity to execute code.

In Java, an array is memory and a reference is a pointer. Java JRE represents the OS containing the arrays and references used by the applet. But, the interaction between these arrays and references doesn't include the runtime security mitigations of the host OS running Java JRE. So, exploiting Java is like exploiting an OS before current runtime security mitigations were available.

Right now, Java uses its sandbox as its runtime security mitigation. Now that methods are known to bypass the sandbox, expect the security mitigations of Java to become a focus until Java figures out a better method to prevent exploits.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.