Do you think Flashplayer will ever be safe? I don't have much use for it, but there are all sorts of web pages that insist on using it. So far, I've left it disabled.
Java and viruses
- Thread starter Fujitsu_Technician
- Start date
Do you think Flashplayer will ever be safe? I don't have much use for it, but there are all sorts of web pages that insist on using it. So far, I've left it disabled.
XPikachu
BSOD
- Messages
- 313
- Location
- Parallel Universe
Flash Player is OK, I just have my firewall settings on high, can this help prevent attacks?
I don't know of any current vulnerabilities in the latest version of flash player, it's certainly had a troubled past but for the moment I think the general consensus is that it's safe - sorry I wasn't trying to worry people!
These days however its use too is fading fast - there's still flash games around sure, but most things such as youtube are gradually migrating across, and with flash unavailable on ios devices this has rather helped the speedup of HTML5 adoption.
These days however its use too is fading fast - there's still flash games around sure, but most things such as youtube are gradually migrating across, and with flash unavailable on ios devices this has rather helped the speedup of HTML5 adoption.
XPikachu
BSOD
- Messages
- 313
- Location
- Parallel Universe
What issues are there in Flash that are so bad anyway?
This site doesn't tell the whole story by any means, and sometimes lists things as vulnerabilities that aren't really as severe as you might think (some for instance involve detailed man in the middle attacks that, while theoretically possible, would take an impractical amount of time and effort for each individual case, unless you're perhaps carrying top secret government files.)
But it does give a rough idea.
But it does give a rough idea.
Last edited:
XPikachu
BSOD
- Messages
- 313
- Location
- Parallel Universe
Wow seem like it is insecure as my back door's deadbolt lock.
Excellent site. I bookmarked it. Floyd
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 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)
True, but as far as I'm aware, every single one of those exploits targets the applet plugin (which everyone knows is a pile of proverbial.)
So the statement:
...as far as I can tell, simply isn't true - at least if you're talking about the runtime environment in the strict sense of the word.
The thing is, if you download and run a Java application on the desktop JRE, then the concept of an exploit becomes a bit blurred - you've downloaded and allowed an application to run in you environment, by definition you've pretty much said "I trust you, do what you want." If that application turns around and does something nasty, that's not really exploiting anything other than user error / stupidity, because the application can do what it likes by design. You could say the same for any application under the sun, Java or not.
Sure thing, but this is almost always down to shoddy coding (especially if things break between minor versions.) Java has the concept of various internal classes that may change at a moment's notice (the com.sun.* branch), as well as various private methods that can be changed in a similar way. Now developers shouldn't rely on any of this functionality whatsoever, but invariably people do, and that's usually how things wind up not being backwards compatible. Sometimes the story is a bit more mixed in major versions, but I've never seen a fundamentally breaking change in a minor version number that's not because a programmer has done something they shouldn't have done.
In this case (from the little reading around I've done) it seems a NullPointerException is thrown with versions 1.6.13+, which I just can't see happening unless the person writing it wasn't coding the way they should have been. I may have made an exception for 1.6.10, which was a relatively major update albeit with a minor release number, but not really for any others.
With desktop Java, sortof (but as I've discussed earlier you've already by this point given the application full privileges anyway so does it really matter?)
With the applet plugin, not a chance - applets are served up in whatever version of the plugin happens to be installed in that browser, and in all implementations of the JVM that I know of, that's the latest one (as it should be.) You can't, as an applet, request a buggier / unstable / previous version of the plugin, that would be insane. You can *check* which version of the plugin you're running under, but that's about it. So saying that the updater leaves "exploitable software" on the system by default isn't really true, unless the updater happened to leave the applet plugin hanging around. If that is true, then it's definitely not just Java that's in trouble, .NET behaves exactly the same way and *has* to much more so than Java because major updates aren't necessarily backwards compatible to the same degree Java is.
In the wake of all these recent exploits that have come to light which are pretty universally to do with the applet plugin, there seems to be loads of articles saying things along the line of "ah just to be sure, you should uninstall Java completely", "just remove it, that way you can be completely safe", "the updater is terrible, it means you're still vulnerable even if you upgrade" and so on. These statements are all false, and I'm not sure why this scaremongering seems to have taken off on such a large scale, but it does seem to have swept the internet in a bit of a storm.
right...
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.
Because you told them to run? you gave the program the ability to run.
well surely by the same logic no viruses are problems then, if you hadn't used that OS, or if you hadn't clicked that file...?
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.
one product and soooooo many security problems.
have a look at the update history.
Java version history - Wikipedia, the free encyclopedia
Java SE 7 Update 13 2013-02-01 50 security fixes
Fifty!!!
but then less than three weeks after that
Java SE 7 Update 15 2013-02-19 5 Security Fixes
another five
a fortnight later another couple of security holes.
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.
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!
as for the scare mongering, the update can leave older versions, (not only is this a pain because it leaves insecure and exploitable software on the system, it also uses up a fair whack of disk space per version installed. (as a note this behaviour seems to have been fixed, though whether it was fixed or I just found the right setting to stop it happening is anyone's guess).
as a test, I've pressed update now.
it's currently saying it's installing update 35, why? who knows why that's certainly not the latest version.
after the update is complete I check the Java version as 1.7._17 (well that's not what it told me it was installing!)
Though it has removed the older version 1.6._ that was on my computer previously. (so the updater's behaviour may have changed...)
anyway, all this goes back to what I was saying originally.
Java, write once run anywhere.
great for developers.
having a huge new attack vector isn't so great for the users.
as far as business software goes, (where you may control the software running on a given machine, and where that machine has access to, such that nobody can find some dodgy jar file to run. then that's OK.
as for applets requesting older version of the runtime environment.
Java Control Panel
If a JNLP file requests a JRE that is not installed, then this option specifies what action is performed...
Applications CAN and do request different versions of JRE, the behaviour is defined, and you can go into the options in the control panel to control and configure what things can run.
which is fine for someone who knows how to.
though even then that leaves someone like myself with the problem that they need a machine with an old insecure version configured to work at request, but there is still no way to say, "only work for this request" or at this time or whatever.
as if to prove a point, the first application I tried to use after updating java tried to request an old version (1.6.23). (that I no longer have installed).
If if was installed then I'd have just gotten a "do you want to run this" message not "do you want to run this version with 173 known security issues" message. (and when you talk about users having installed and therefore allowed code to run on their system there is a huge difference between these messages.
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.
Because you told them to run? you gave the program the ability to run.
well surely by the same logic no viruses are problems then, if you hadn't used that OS, or if you hadn't clicked that file...?
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.
one product and soooooo many security problems.
have a look at the update history.
Java version history - Wikipedia, the free encyclopedia
Java SE 7 Update 13 2013-02-01 50 security fixes
Fifty!!!
but then less than three weeks after that
Java SE 7 Update 15 2013-02-19 5 Security Fixes
another five
a fortnight later another couple of security holes.
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.
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!
as for the scare mongering, the update can leave older versions, (not only is this a pain because it leaves insecure and exploitable software on the system, it also uses up a fair whack of disk space per version installed. (as a note this behaviour seems to have been fixed, though whether it was fixed or I just found the right setting to stop it happening is anyone's guess).
as a test, I've pressed update now.
it's currently saying it's installing update 35, why? who knows why that's certainly not the latest version.
after the update is complete I check the Java version as 1.7._17 (well that's not what it told me it was installing!)
Though it has removed the older version 1.6._ that was on my computer previously. (so the updater's behaviour may have changed...)
anyway, all this goes back to what I was saying originally.
Java, write once run anywhere.
great for developers.
having a huge new attack vector isn't so great for the users.
as far as business software goes, (where you may control the software running on a given machine, and where that machine has access to, such that nobody can find some dodgy jar file to run. then that's OK.
as for applets requesting older version of the runtime environment.
Java Control Panel
If a JNLP file requests a JRE that is not installed, then this option specifies what action is performed...
Applications CAN and do request different versions of JRE, the behaviour is defined, and you can go into the options in the control panel to control and configure what things can run.
which is fine for someone who knows how to.
though even then that leaves someone like myself with the problem that they need a machine with an old insecure version configured to work at request, but there is still no way to say, "only work for this request" or at this time or whatever.
as if to prove a point, the first application I tried to use after updating java tried to request an old version (1.6.23). (that I no longer have installed).
If if was installed then I'd have just gotten a "do you want to run this" message not "do you want to run this version with 173 known security issues" message. (and when you talk about users having installed and therefore allowed code to run on their system there is a huge difference between these messages.
