Slashdot Mirror
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."
As far as I've been concerned, Java and Javascript have both always been security menaces.
Letting web-sites and advertisers execute code has been a recipe for problems for a long time, which is why many of us here likely already block it.
This is just another example of why we can't trust the companies doing the advertising, because they're part of the problem -- if Yahoo is serving malware, Yahoo can't be trusted.
Lost at C:>. Found at C.
This wouldn't be an issue if they could only serve image or text only ads. Possible image based exploits can easily be prevented by re-saving the uploaded image so that the image only contains valid content.
But no, ad farms want to provide functionality to reach maximum annoyance for the users. You can blame Java all you want, but it's not the source of this problem.
Source unknown? Bullshit! Yahoo didn't run the ads without payment. Payment == traceable. Or is Yahoo accepting Bitcoins now?
It has been my contention that when websites no longer serve malware through Ads, then they can start complaining that users blocks ads. This is not an uncommon occurrence, even for large websites, and the fix is not always immediate. I recall not that long ago when the New York Times was serving malware for the entire weekend.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
yep, blocked *.yahoo at the point i noticed them installing psudo-malware with uTorrent (the persistent default search engine replacement software which uses far more CPU time than something that supposedly just monitors search engine settings and resets them to Yahoo should. It was very malware like in it's choice of installation folder too and of course the fact it was both unwanted and self-repairing)
once a company starts doing that shit they end up on my block list, permanently. uTorrent made it too for bundling the crap.
sounds like I dodged a bullet by having them blocked.
The moment that Yahoo allowed advertisers to use java they knew that minimally those ads would be used to annoy the crap out of the users. If your ad is a static picture with a clickable link then you don't need Java. What you need java for is to start prying into the user's business. Animations, sound, geolocations, saving data to the user's machine. So any "legitimate" ad using Java is halfway to being malware already. Plus why use Java instead of Flash? Generally ads should be made by Graphic artist types who are more familiar with Flash. Thus the primary reason to use Java is to access some feature that flash has blocked in Flash.
So if your goal with a Java ad is to circumvent something that Adobe has blocked then it probably should remain blocked. On top of that most users have turned off Java so it can't be to reach a wider audience.
So when Yahoo allows advertisers to use Java they knew perfectly well that the advertisers were up to no good whatsoever. Their acting surprised that some of the scumbags took it even further is total BS.
Basically at this point, anyone who has Java turned on in the browser is the same as having a house with a weeks worth of newspapers stacked up at the front door. Effectively a greeting card inviting the criminals in.
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.
There's no place I could be, since I've found Serenity...