Java flaw allows “complete” bypass of security sandbox
arstechnica.com
arstechnica.com
And for sure it is, on a fulldisclosure list, nothing is revealed. My monocle dropped in my morning Java.
* http://scarybeastsecurity.blogspot.co.uk/ * http://www.scary.beasts.org/security/
I would imagine we are going to see more and more of these exploits unless Oracle takes the same approach that Microsoft took, and even then it will be years before the benefits are felt.
One other thing before I go- are other JVM languages affected by these bugs?
Second, the parent wasn't comparing the products but the security practices followed; MS's hardcore security practices are well known and have served them very well over the last decade. The products they make have little to nothing to do with this.
Lastly, the language you use has absolutely nothing to do with this bug -- it's a JVM bug itself.
(Not trying to rag on MS.)
... except SELinux.
Taking a guess I would imagine its because the JVM is doing something it shouldn't be, similar to how Adobe products continually have flaws found in them, which isn't the fault of the OS.
If that's the case blaming Microsoft would be like blaming the Linux kernel for being exploited when the actual attack was against a service like Apache running under the root account. Unless you intelligently run things under proper accounts all the OS security in the world won't save you if there is a flaw in something running on it.
the flaw would be exploitable on any machine with Java 5,
6, or 7 enabled (whether it’s Windows 7 64-bit, Mac OS X,
Linux, or Solaris
[...]
“An attacker could then install programs, view, change,
or delete data with the privileges of a logged-on user.”
Who uses Java in browser anyway? WebEx and some weird VPN solutions?
Chase requires Java to see pending Checks for business banking w/ fraud protection which lets you OK or reject checks before they're detected from your account.
Whereas they have scanned JPEGs for account history check images, the pending fraud control check images require Java.
I am willing to wager your credit union is not paying you 3.5% APY on your checking account. That is, if you had $10,000 in your checking account at the end of the year, and you just left it there, you would not have $10,375 at the end of year.
There is a restriction/surcharge in there that you haven't mentioned.
I wish I could re-finance my mortgage at 3.375% fixed. :(
This is why I don't understand why people keep going back to banks and getting screwed every single time. The bank is there to make money off its customers; the credit union, by definition, is there to make money for its customers.
https://www.kemba.com/checking-savings/checking/get-green-ch...
We are typically asked to write checks by lawyers :) Everyone else has moved to electronic banking.
Checks are also handy for one-off payments to people (not companies!) you don't know and won't meet again.
Of course in the Enterprise where about 50% of our end-users are, it's still easier to tell them that they should install Java rather than something they don't know.
Which leads to us having to support both methods.
We have a similar case though with printers.
That they've inherited a huge, complex codebase is unfortunate.
I think any program or VM, Ruby, Flash, Python, whatever would end up with the same number of security holes if it had the user base to attract attention from hackers.
But, it bears mentioning that Ruby and Python aren't a mainstream part of browsers. And Flash (under Adobe) has actually done some pretty impressive stuff recently with regard to sandboxing.
It's a major pain in the ass, and it sucks, but it's true.