I am dismayed, JGO. My PC was acting really strange, so I did my first virus scan of the year, and found 3 Java virsuses! I keep my Java up to date and everything! So, that really sucked. Good news is they’re all gone now, but still. If people get viruses like that they’ll blame Java. :<
I would blame all the p0rn sites and all my uncautious downloads and installs. Nothing else.
The article that the quote is from may now be dated (a year old, after all).
[quote]On the basis of the total statistical data of this study it is documented that following products frequently are abused by malware in order to infect Windows machines: Java JRE, Adobe Reader / Acrobat, Adobe Flash and Microsoft Internet Explorer.
[/quote]
From the following URL;
I’m still not aware of a Java vuln in the wild that can bypass a user dialog intervention.
I don’t run virus scans - was without virus checking for 10 years until I caved and got MS Security Essentials (the only virus checker worth having on Windows). To date it’s found bugger all. It’s easy to live without one if you don’t go looking for trouble. I just hang out on the same 15 websites and rarely go anywhere off the beaten path.
Cas 
I’ve had a case or two myself; never related to the JVM of course. MSE picked it up before I even had the chance to run an executable. Perhaps it won’t catch all the baddies out there (tests have proven that it does not perform so well as its competition when it comes to actually recognizing threats) but when it does work, it works really well.
I’d put money on that claim stemming from all the malware crud that triggers false positives. That happens too often in relation to java classes.
I’ve never personally seen this vulnerability, but search up the java atomicreference array flaw.
Pretty serious stuff.
I got a Java “virus” once from a tv show online streaming site. There were no dialog box, I just noticed the java icon pop up in the notification bar and next thing I know I had an annoying application installed on my computer. Luckily it was quite harmless and could (almost) be removed from the control panel 
Mike
And your friends’ dirty usb >_>
should we also be aware on showcase entries too? 
[quote=“princec,post:4,topic:39300”]
Drive-by-attacks are actually the main way to get infected these days (by java). They require no user interaction and typically don’t bother you, but needless to say you instantly become part of a botnet.
As for not looking for trouble: it only requires a perfectly harmless site (like jolly good old JGO) to get infected, and you’re screwed.
[quote=“Riven,post:9,topic:39300”]
May I ask “How?”, and continue chewing my gumdrops in a happy mood?
Let’s say you want to infect JGO. As it’s an SMF site, it’s not that hard: there are lots of SQL injections possible. As SMF is a design flaw to begin with, data is htmlentities-escaped before it is inserted in the database, so… unfortunately, SMF assumes that everything in the database is safe to send to the browser, without further checking. Combine this with the ability to inject arbitrary data in the database, and you should see how it is possible to put “<applet …>” in there without too much effort. Next step is to write a mallicious applet that can escape the sandbox. There are enough examples of this on the web, so yes, that is indeed possible. Now we can write an executable to disk and call Runtime.getRuntime().exec(…) to launch it. Piece of cake, really.
How in the world does that work? I thought rule #1 in safe web-programming, is to not send the “<” char as “<”, but rather <, which is not picked up as html? Isn’t it possible to fix those before the data goes into the db?
'o course, I don’t run applets on websites anyway, I’ve got Chrome to stop it
So I feel a bit safer.
Cas 
Yeah, me too. I think most browsers do that. I’d still like to know about that flaw in SMF, as I can’t imagine anyone would leave it there.
Sure, this might be the reason you said that you didn’t see a mallicious applet that didn’t require user-interaction to launch. Obviously, the Chrome developers only added this because the Java Plugin itself failed to be secured by their user-interaction.
But I have the feeling that I’m explaining things you already know, so I’ll stop right here 
It’s not just 1 flaw. It’s hundreds (if not thousands) of flaws. It’s beyond repair.
This is exactly the flawed reasoning that the SMF devs had, which made it fail, security wise. 
It should be escaped after it is read from the database.
Don’t trust your database, treat everything inside is as ‘data’, not ‘information’. Say you notice a flaw in your insert/update sanity checks… you fix it, but all the data inside your database is still ‘infected’. It might not even be possible to run a query that corrects it, because that would mean data-loss.
Now reverse the situation: dump everything you receive in the database, as is, and escape the data after you received it from a query. When you ‘fix’ the flaw in your escaping now, all existing data, no matter how mallicious, will be safely escaped by the new algorithm. For added benefit: you can escape it for either HTML, javascript, Java, XML, SQL, whatever. As you haven’t altered the original data, you’re free to transform it any way you like.
There’s thousands of flaws? I agree with what you said about the database, however wouldn’t that be a rather large operation to perform every time someone requests data? Why is it that making the assumption that you are the only one with access to the database is not safe? Is it that easy to access and edit a database?
It’s about keeping the original data. The database is typically not unsafe by definition, but the lack of prepared-statements, and thus SQL injections make it a hostile place.
If somebody want to edit data, and the data is escaped, you have to unescape it, edit it, and escape it again. Unescaping is not always possible, as the transformation is not always purely escaping: you’ll often find ‘sanitized’, which means you lost data.
An no, escaping data every time it’s retrieved from the database is not slow.
It’s about keeping the original data. The database is typically not unsafe by definition, but the lack of prepared-statements, and thus SQL injections make it a hostile place.
If somebody want to edit data, and the data is escaped, you have to unescape it, edit it, and escape it again. Unescaping is not always possible, as the transformation is not always purely escaping: you’ll often find ‘sanitized’, which means you lost data.
An no, escaping data every time it’s retrieved from the database is not slow.
I’m quite shocked that you were able to dictate what I load so easily. Isn’t this quite the large hole in security? Since anyone can post on here, it would be easy to drive-by everyone that reads any given page.