Java and viruses

[berry120]

So you're saying that exploits, malware and viruses that can enter a system where Java (or at least the JRE) as a vector are not important.

Not at all - I'm saying that there comes a point where once you allow an application to run beyond a certain level, the vector pretty much becomes irrelevant. I could knock up a .NET application, a Java application, Delphi app, VB.NET app, C app, C++ app, etc. that would trounce through a user's files, corrupting anything that it had access to and came accross.

(No, it's not an argument for Java being more or less secure than anything else, it was more of a side point.)

The point is that Java does open new vectors for attack simply because it adds new methods for running code which should run in a reliable way, (or does run in a reliable way) at the OS layer, but in the abstraction layer that the runtime is adding nefarious things are happening. -i.e there is no way for the OS to adequately see that some kind of exploit is attempted.

Exactly, and there have been a ton of vulnerabilities of this nature exposed recently.

But here's the clincher, and what I keep continually coming back to with this argument - pretty much all of these vulnerabilities have been exploits centred around the applet plugin.

However, I do have a confession to make at this point, in that when I was saying the "applet plugin", I was also referring to the web start plugin (that's the one that's used to load up JNLP files) that's based on the same architecture - sorry for any confusion there. As far as I'm concerned, it's another flawed design and I failed to mention it simply because it's been so long since I've last used it (and conceptually I tend to view the two things as one for various technical reasons over how they work.) By desktop Java, I pretty much mean solely downloading programs via conventional methods, written in Java, installing them and running them with a provided JRE.

A side note: The JNLP plugin doesn't necessarily cause as many security problems as vanilla applets though purely because its vulnerabilities aren't drive by - with a lot of the applet based problems, they are (you can "catch" a virus simply by visiting a web page with an embedded applet.) With a JNLP file, you actually have to download and run that file; granted it's not a secure mechanism but there is at least an extra step there.

Just to show the point, let's take a look at those 50 security fixes included in the update, details are here. Note that all of them have notes, saying what technologies they refer to. Out of those 50, 43 of them have the following note:

Applies to client deployment of Java only. This vulnerability can be exploited only through untrusted Java Web Start applications and untrusted Java applets. (Untrusted Java Web Start applications and untrusted applets run in the Java sandbox with limited privileges.)

So that leaves a grand total of 7 security updates that don't fit into this category (and even then, 2 are server side issues that have nothing to do with client side Java, one is a vulnerability that can't be used to achieve anything on its own, and the rest bar one involve either web start / applets or server side web service calls.)

I agree with your last part showing that JNLP / web start can request specific versions of Java (as in that's a silly design choice if you ask me.) And I've no idea how the updater works, I don't think it's flawed in the security sense but it is bizarrely implemented (I don't use it, as a Java developer I always do manual installs of the JDK which I need rather than just the JRE.)

I think Oracle have finally got it right in that the latest JavaFX toolkit now contains build tasks to produce platform dependant installer packages that are more secure (and that users expect.) Seems The write-once, build-many, run-anywhere approach just seems fundamentally better to me than write-once, build-once, run-anywhere-and-try-to-deal-with-the-problems-as-they-appear approach. I use this approach, running an automated 3-tier build system for my projects (I get a .exe installer, .deb package, .dmg package and .jar cross platform installer out the other end.) That's what I class as "desktop Java", the more traditional approach - and I fully maintain that Java in that sense of the word is as secure as anything else.

I understand that things can change in what may be executed in code, but I doubt that IBM rolled out worldwide a piece of hardware containing a processor running code to be interoperated by the JRE that was a bit sloppy doing things it shouldn't have.

I don't doubt that at all - it happens all the time, with big and small corporations alike. The fact that it "worked then" also meant no-one probably bothered to look in more detail about what the code was doing, so didn't spot the problem - I've got no proof, but experience tells me this is almost certainly the IBM devs doing something wrong rather than Sun introducing a major backwards incompatible change in a minor version update.

how do you define the ways you should use something? if something is good code, and it works, BUT using a feature in a slightly different way is a bug or can lead to an exploit, then Sun's fix was just to rip out the feature, and to hell with a million of so integrated hardware devices deployed over the world. -they will have to use the old buggy version that we know if full of security holes!

Too much to go into here in detail, but suffice to say as a Java dev there's various well defined conventions that you should stick by if you want your code to be future-proof. Things like not reflecting to access private methods on library classes, not using com.sun.* classes, not doing painting in Swing unless it's on the EDT, not doing painting in JavaFX unless it's on the Platform thread (actually the last two are of conventions just to ensure your code works reliably in *any* version, but still.) Some of these mistakes are easy to spot (such as searching for any used com.sun classes), others are more tricky. (I don't think it's anything to do with exploits.)

 

[FloydV]

For what it's worth...

I agree with the sentiment of the original poster.
if you have a look at most Java updates for version 1.6.1 to version 1.6.?? (currently at version 43) most updates are security focused, because The Java runtime environment opens up a host of exploits for the OS.

In just this last week new patches and updates have been issued for JRE because there are exploits, and they are being used in the wild.


Worse still the default behaviour for client updates are to add the new client, but leave the old client available.
Often updating the JRE can break something that some software depends on. (for example the remote desktop on RSAii cards (remote supervisor adapter) for IBM servers that provides out of band access does not work in JRE 1.6.13+ because functionality previously acceptable or recommended is removed.

but that's actually OK, because as I said, the default behaviour is to leave clients installed, and applications can request a different version of the JRE to the current installed latest...


Which leaves us with the following recommendations.

Update your version of the JRE,
Remove older versions of JRE
Hope and prey that they Java based software you're using wasn't relying on a quirk of the environment that's no longer available.

and all so you can run an application...
Java is good for developers with it's write once run anywhere nature.
but it's also good for malware and virus writers, with it's annoying updater that a lot of people get infuriated with an disable, an updater that leaves exploitable software by default on a system.

good for developers, yes.
good for end users... debatable... (and that's before you get around to the question of running a runtime environment (with multiple layers) on-top of an OS)

I certainly agree with your last statement. But, just for clarity, are you talking about Javascript, JAVA, or both when you talk about updates and security issues? I know you are right about updates not removing old versions, because I've had to remove those manually. Floyd

 

[berry120]

I certainly agree with your last statement. But, just for clarity, are you talking about Javascript, JAVA, or both when you talk about updates and security issues? I know you are right about updates not removing old versions, because I've had to remove those manually. Floyd

Just Java here - Javascript is a completely different (and mostly unrelated) technology that just happens to be similarly named.

 

[FloydV]

Just Java here - Javascript is a completely different (and mostly unrelated) technology that just happens to be similarly named.

I went to the Java settings in control panel, and it tells me what version I am using and there is a box that is checked. However, it refuses to let me un-check the box. If I wanted to turn regular Java off to see what effects that might have, how would I do it?

Floyd

 

[_michaelm]

berry is correct on numerous counts

1) The java applet which installs into your browser is responsible for a significant number of vulnerabilities which are exploited by malicious websites (specifically not viruses here!).

2) Having Java Runtime Environment (the JRE) on your PC does not lower your security in any way - however if you don't use any java applications locally then there really is no point in having it.

3) Javascript is a web-based scripting language which is executed natively by your web-browsers javascript engine - it has the ability to load a Java applet, but unlike Java, javascript cannot a) access your filesystem b) alter your registry c) start any other processes (outside of the browser) on your machine

A quick rundown on terminology for things commonly mislabeled as viruses.

1) A virus is malicious, executable code, which requires user interaction to run and (optionally) propagate

2) An exploit (in the context of the web) is most often malicious script (javascript/php/ruby/perl/python - all web scripting languages) which takes advantage of a vulnerability

3) A vulnerability is an error in a program/application which when provided with crafted input can be made to do something the original developer did not intend - an exploited vulnerability results in the host machine being compromised

4) A worm is an autonomous executable which has the ability to propagate without user interaction

5) A trojan is what most people mislabel a virus, this is usually what is delivered as a payload via compromised websites - often via exploit packs. Trojans are native executables which typically feature rootkit, dropper (aka downloader) and/or backdoor functionality

6) An exploit pack is a collection of tens (sometimes hundreds) of individual exploits bundled into a collection which are all launched at victims visiting compromised websites (often websites have been unknowingly injected with a link to the malicious site hosting the exploit pack)

7) A rootkit is a malware component which hijacks the operating system api calls and allows hiding of files and processes from the user - making them very difficult to remove

8) A dropper is a malware component which itself is relatively benign (many many droppers are out there, and are refreshed daily, to avoid detection by AV signatures). Once on your system and running, droppers connect to preconfigured remote websites and download further malware (usually another component of the malware has disabled your AV by this point so even though you may have signatures for the 'real' payload, it's too late).

9) Finally, a backdoor is a malware component which opens a listening port on the infected machine and enables remote login by the controlling 'bot-master/bot-herder'

There are obviously loads more terms in this environment - but frankly definitions can easily be found online - but for the sake of a lot of common misconceptions I thought I'd put a few up.

 

[FloydV]

berry is correct on numerous counts

1) The java applet which installs into your browser is responsible for a significant number of vulnerabilities which are exploited by malicious websites (specifically not viruses here!).

2) Having Java Runtime Environment (the JRE) on your PC does not lower your security in any way - however if you don't use any java applications locally then there really is no point in having it.

3) Javascript is a web-based scripting language which is executed natively by your web-browsers javascript engine - it has the ability to load a Java applet, but unlike Java, javascript cannot a) access your filesystem b) alter your registry c) start any other processes (outside of the browser) on your machine

A quick rundown on terminology for things commonly mislabeled as viruses.

1) A virus is malicious, executable code, which requires user interaction to run and (optionally) propagate

2) An exploit (in the context of the web) is most often malicious script (javascript/php/ruby/perl/python - all web scripting languages) which takes advantage of a vulnerability

3) A vulnerability is an error in a program/application which when provided with crafted input can be made to do something the original developer did not intend - an exploited vulnerability results in the host machine being compromised

4) A worm is an autonomous executable which has the ability to propagate without user interaction

5) A trojan is what most people mislabel a virus, this is usually what is delivered as a payload via compromised websites - often via exploit packs. Trojans are native executables which typically feature rootkit, dropper (aka downloader) and/or backdoor functionality

6) An exploit pack is a collection of tens (sometimes hundreds) of individual exploits bundled into a collection which are all launched at victims visiting compromised websites (often websites have been unknowingly injected with a link to the malicious site hosting the exploit pack)

7) A rootkit is a malware component which hijacks the operating system api calls and allows hiding of files and processes from the user - making them very difficult to remove

8) A dropper is a malware component which itself is relatively benign (many many droppers are out there, and are refreshed daily, to avoid detection by AV signatures). Once on your system and running, droppers connect to preconfigured remote websites and download further malware (usually another component of the malware has disabled your AV by this point so even though you may have signatures for the 'real' payload, it's too late).

9) Finally, a backdoor is a malware component which opens a listening port on the infected machine and enables remote login by the controlling 'bot-master/bot-herder'

There are obviously loads more terms in this environment - but frankly definitions can easily be found online - but for the sake of a lot of common misconceptions I thought I'd put a few up.

So, if I interpret you correctly, the real danger is in the Applet itself, not in Javascript. That is bothersome, because most of the add-ons in Firefox don't say anything about what code they are using. Some reference a .dll, but that is all I see. Given that small amount of info, it isn't possible to say whether an applet is vulnerable or not. Would you agree?

Floyd

 

[_michaelm]

Firstly don't confuse a java applet with a firefox addon - firefox addons can be written in java (or any other language really) but I don't believe they typically are, someone please correct me on that otherwise.

That aside, you are correct to assume that (in this specific situation) the danger is likely to be in the applet rather than the 'innocent' javascript which simply invokes the applet. However, the applet is delivered as java bytecode through the browser (hence must also be stored on this webserver - which is hard to do if you don't own it) and this can be reversed/analysed for malicious activity in just the same way as any traditional assembly instructions are reversed for native windows binaries.

A good way to think about what is more dangerous is to question what is more likely to get by the average user without concern? Consider the following two scenarios:

1) Person visits 'questionable-website.com' which hosts innocent javascript but a malicious java applet. To run, this might display a dialogue box requesting execution - depending on the users browsing habit

2) Person visit 'everyday-website.com' which has been compromised and injected with malicious javascript via a 1x1 pixel image from 'really-bad-website.com' - this resource points to an exploit pack launching server which fires attacks at your browser until one succeeds

Whilst I appreciate I have amplified the point in the above scenarios - situation 2) would be much more effective because a) more people visit 'everyday-website.com' and b) more people allow javascript than java applets

Again, there are more reasons, but these are the main ones

Hope that helps

 

[FloydV]

Firstly don't confuse a java applet with a firefox addon - firefox addons can be written in java (or any other language really) but I don't believe they typically are, someone please correct me on that otherwise.

That aside, you are correct to assume that (in this specific situation) the danger is likely to be in the applet rather than the 'innocent' javascript which simply invokes the applet. However, the applet is delivered as java bytecode through the browser (hence must also be stored on this webserver - which is hard to do if you don't own it) and this can be reversed/analysed for malicious activity in just the same way as any traditional assembly instructions are reversed for native windows binaries.

A good way to think about what is more dangerous is to question what is more likely to get by the average user without concern? Consider the following two scenarios:

1) Person visits 'questionable-website.com' which hosts innocent javascript but a malicious java applet. To run, this might display a dialogue box requesting execution - depending on the users browsing habit

2) Person visit 'everyday-website.com' which has been compromised and injected with malicious javascript via a 1x1 pixel image from 'really-bad-website.com' - this resource points to an exploit pack launching server which fires attacks at your browser until one succeeds

Whilst I appreciate I have amplified the point in the above scenarios - situation 2) would be much more effective because a) more people visit 'everyday-website.com' and b) more people allow javascript than java applets

Again, there are more reasons, but these are the main ones

Hope that helps

Now I'm confused about the difference between applets and add-ons. When I go to add-ons, I can see Adblock Plus which is enabled, and when I look at Extensions, I have Garmin Communicator, which is enabled. Where would I look for applets?

Floyd

 

[berry120]

Now I'm confused about the difference between applets and add-ons. When I go to add-ons, I can see Adblock Plus which is enabled, and when I look at Extensions, I have Garmin Communicator, which is enabled. Where would I look for applets?

I think what's confusing the matter here is "add-ons" and "extensions" - there is a somewhat subtle difference, but assume they're essentially the same thing (they're similar.) I'll refer to them both here as add-ons.

Add-ons are essentially plugins which offer additional functionality in your browser, perhaps supporting other content types (such as the flash plugin) or perhaps providing extra buttons that help with referencing (zotero plugin) - pretty much anything at all.

The applet plugin is a specific plugin that, when installed in your browser, allows it to run Java Applets which may be embedded in a web page. The applets are the things written in Java that the applet plugin can run, a bit like the fact the flash plugin can load and play SWF files.

 

[FloydV]

OK, that was the piece I was missing. The applet plugin is buried in the Firefox code, or can it be turned on and off?