Yahoo Advertising Serves Up Malware For Thousands

wjcofkc writes "Thousands of users have been affected by malicious advertisements served by ads.yahoo.com. The attack, which lasted several days, exploited vulnerabilities in Java and installed malware. The Netherlands based Fox-IT estimates that the infection rate was at about 27,000 infections per hour. In response to the breach in security, Yahoo issued the following statement, 'At Yahoo, we take the safety and privacy of our users seriously. We recently identified an ad designed to spread malware to some of our users. We immediately removed it and will continue to monitor and block any ads being used for this activity.' While the source of the attack remains unknown, Fox-IT says it appears to be 'financially motivated.' The Washington Post cites this incident as a reminder that Java has become an Internet security menace."

Re:adaware

[Anonymous Brave Guy]

It has been my contention that when websites no longer serve malware through Ads, then they can start complaining that users blocks ads.

Indeed. I block 100% of ads my tools can identify, I consider this a routine security precaution, and I make no exceptions. Sorry to the honest site operators, I won't take offence if you decide to block me because I block your ads, but no, I won't whitelist you. This became my policy shortly after the only virus infection I've ever been aware of picking up on any computer I operate, which was a Java zero day exploit I picked up browsing normally reputable tech news sites.

Re:Become?

[gstoddart]

Yup, didn't trust that either.

NoScript, AdBlockPlus, Ghostery, ScriptSafe, and everything else you can find to keep the crap at bay is the only safe way to use the internet these days.

Between advertising companies who feel entitled to your data, and all of the crap on the internet ... leaving that stuff on by default is just asking for problems.

Freaking ad networks

[Dega704]

Hence why I advise people to install AdBlock on their browsers. The way things have been for the pas few years, it's probably more effective than antivirus software. (Before you flame me, I am speaking tongue-in-cheek. You really should have both.)

Yes, really

[cbhacking]

With all due respect, his post was a lot more insightful than yours. You don't appear to know what you're talking about.

First of all, "deployed the same way" as in "deployed using an HTML <object> or <applet> element that instructs the browser to download and execute the code". The Microsoft Visual C++ redistributable runtime does not include any such mechanism for deploying C++ code. For that matter, not all Java runtime installations do either.

Second, just what do you think ActiveX is programmed in? Hint: it's not its own language. It's a packaging system for COM classes, which are almost without exclusion written in C++, and it *is* possible to deploy and run it in the browser in much the same way as Java applets (object tags). Unlike Java, they run with basically no sandbox but instead require considerable amounts of confirmation before they download. The idea is that they are powerful but unsafe, so only use the ones that you trust. Unfortunately, a number of pre-installed ActiveX controls on Windows have security vulnerabilities in them, so an attacker who finds a way to exploit one of those pre-installed ones doesn't need to get the user to download anything. Hence the way that modern versions of IE require the user to confirm before running an ActiveX control that they've not previously indicated that they trust (and also give you an ability to disable ActiveX completely or only enable it on a site-by-site basis).

I don't care for the Java installer any more than you do, but the security issues with Java applets have literally nothing to do with the language. The only way you could say Java itself is at fault is if you were to argue that Java shouldn't have any OS bindings at all (that is, no ability to access the file system, no ability to create processes, no ability to open network sockets, etc.). This is essentially the situation with JavaScript, of course; while the Java applet sandbox tries to *restrict* the use of functionality like I just mentioned, the JavaScript runtime (as found in browsers) simply lacks APIs to access such risky features. Even there, though, that's not a characteristic of the JavaScript *language* but merely of the sandboxed runtime used to execute JS in the browser. Other uses of JS, ranging from Windows Script Host to Node.JS, are perfectly capable of doing such things.