Slashdot Mirror
Dangerous Java Flaw Threatens 'Virtually Everything'
Marc Nathoni writes with a ZDet article about a critically dangerous hole in the Java Runtime Environment. Due to the ubiquitousness of Java, this could prove a serious security problem. "Australia's Computer Emergency Response Team (AusCERT) analyst, Robert Lowe, warned that anyone using the Java Runtime Environment or Java Development Kit is at risk. 'Delivery of exploits in this manner is attractive to attackers because even though the browser may be fully patched, some people neglect to also patch programs invoked by browsers to render specific types of content,' said Lowe."
When I told them NoScript was a great plugin.
SmartBox
Okay, so which versions are vulnerable?
The article contains virtually no information about the exploit. "There's a vulnerability. And it's really scary" is about all I got out of this.
No offsense, but that's a rather incredible claim. They're saying that no matter if you're running a JVM on the server, cell phone, applet, desktop, or just about any other environment, you're vulnerable? I'm sorry, I can't accept that without extraordinary proof to back up such extraordinary claims.
Java was designed from the beginning with security in mind. Its security infrastructure has been tested for over a decade now. Any and all exploits have always been a flaw in the specific JVM or interface between the JVM and the OS. (Something which has been plauging browsers and other network-aware applications.) Now some security expert is saying that it doesn't matter what you're doing because Java as a whole is flawed?
It seems more likely to me that they're blowing the whole thing out of proportion and thereby spreading FUD. It's more likely that it's yet another security hole in specific JVMs and someone here is expanding that to all of Java. I'll happily look at the evidence to the contrary as soon as it becomes available.
Oh, and upgrades for Desktops is not too big of a deal. Java currently includes an autoupdater that should take care of the issue. All that's left is to deploy updates to servers, should these fellows actually prove that the language you're using somehow conveys a serious security through port 80.
Javascript + Nintendo DSi = DSiCade
Does anyone have any details on this beyond "virtually everything is threatened?"
Does anyone have a link to the actual "Google Security Team" report on the issue, or an announcement from them on having discovered the issue?
The article rages about the whole universe being at risk (ignoring the fact that Java has had an auto-update mechanism for quite a while) but doesn't say which JVMs are at risk.
I can't actually find ANYTHING else beyond the chicken licken article here on what the issue is.
An Eye for an Eye will make the whole world blind - Gandhi
I'd say borderlining FUD. What help is it to tell us that there's some huge security bug without telling us what it is?
What about the people using it to run nuclear reactors?
The browser plug-in is based on gcc.
There is enough meat in this article to make a whole stack of boca burgers.
For an additional undetermined sum, Pure Hacking will offer an ambiguous and nefarious fix for the vulnerability.
WARNING! WARNING! WARNING! WARNING! WARNING!
Wouldn't you just roll it out the same as with any other patch?
Without any more information and judging from comments such as that, I'm going to say that this "threat" will soon be found to be nothing. Just more Internet hype from someone trying to make a name for himself.
I'm pretty sure this is it:
1 63fb0cc55
http://groups.google.com/group/ph4nt0m/msg/05b113
One huge problem I see with this is that not only are users generally unaware of what JRE/JDK they're using, they may not even know that they're using one at all. Some software like to install their own JRE version, so a user might have three or more different versions spread around the system, which needs rooting out (I suggest "c:\>dir rt.jar /S" on windows machines)
Java != Javascript
If you're paranoid, at least disable the right thing.
This CNET article has more information. There is a vulnerability report at Sun. It is fixed in JDK and JRE 5.0 Update 10 or later, SDK and JRE 1.4.2_13 or later and SDK and JRE 1.3.1_19 or later.
was nearly as underwhelming as Microsoft's E3 showing
Pow, Right in the kisser!
Summation 2
>>Due to the ubiquitousness of Java, this could prove a serious security problem.
Ah! That would be 'ubiquity' then?
FFS editors!
About a page up, someone mentions that the NoScript Firefox extension can block Java applets, which is probably a more convenient choice rather than disabling Java all together.
Another point for Firefox! Against IE at least.
I was about to reply then realised I'd been trolled!
Could they manage to say less in this article? There's no reference to what the flaw is, how bad it is; anything. The mention that Google Engineers found it, and then some analysts talk about how it could be a problem for all browsers that have a JVM, which sounds analysty and most likely wrong.
I did a search on Google News and came up with nothing BUT this article.
Anyone have anything more concrete?
- The Amazina Llama
I agree, but, since when has patching been easier on something else?
Is... is that a threat? A threat from a bogeyman waving a "The End of the Java World is Nigh" sign?
crazy dynamite monkey
Java != Javascript
How many times have we seen this comment...
--
The world is divided in two categories:
those with a loaded gun and those who dig. You dig.
It looks like AusCERT has published on their page about this:
- 2007-2788
- 2007-2789
Quoted from
AL-2007.0071 -- [Win][Linux][Solaris] -- Sun Java Runtime Environment vulnerability allows remote compromise
1. Impact
A buffer overflow vulnerability in the image parsing code in the Java
Runtime Environment may allow an untrusted applet or application to
elevate its privileges. For example, an applet may grant itself
permissions to read and write local files or execute local
applications that are accessible to the user running the untrusted
applet.
A second vulnerability may allow an untrusted applet or application to
cause the Java Virtual Machine to hang.
Sun acknowledges, with thanks, Chris Evans of the Google Security
Team, for bringing these issues to our attention.
These issues are also referenced in the following documents:
CVE-2007-2788 at
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
CVE-2007-2789 at
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
That last line should read, "serious security risk through port 80."
I find it interesting that this team is supposedly reporting a major flaw, yet manually running the Java updater finds no new JVM versions to download. Didn't they contact Sun first? Shouldn't there be a patch already? Meh. The whole thing stinks.
If you want to run the updater yourself, you can either right-click on the Java icon in your taskbar and select "Control Panel", or you can run the "javacpl.exe" file in the "c:\Program Files\Java\jre\bin" directory. Look under the "Update" tab to see the update schedule. Click "Update Now" to check for the lastest release.
Mac users do not need to access a separate updater. Java updates are pushed through the standard system updates, accessible through the control panel. These are also scheduled to run on a regular basis. Only Linux/Unix users should need to manually update their JVMs if and when a patch becomes available. Some of these OSes do have a Java updater, but I don't know the current details about these.
Javascript + Nintendo DSi = DSiCade
That was yet another serious Java bug. Unless they've decided to review a story from January, which I guess is always possible.
Friday the 13th is the new April Fool's Day!
Well, we have a gut feeling that there is a vulnerability...
The article has no information what so ever - but, perhaps that is to avoid spreading information on how to exploit this alleged weakness.
First, this is more than a month old and has been patched. And B, ubiquitousness isn't a word. Not even in Australia.
It appears to be referring to the GIF exploit, which was patched a couple of months ago.
And the article is correct, attempting to patch vulnerable JVMs turns out to be practically impossible. The problem is that most Java enterprise software winds up becoming tightly coupled with a specific JVM. (In Oracle's case, a good half-dozen *different* JVMs!) You can't upgrade the JVM without breaking the enterprise app (trust me, I tried, they really work only with the specific JVM shipped), so you're left with vulnerable JVMs and no way to upgrade them.
I don't have a solution to that problem. The one plus side to Java vulnerabilities is that Java runs on many platforms, so it may be slightly harder to exploit a flaw. But it's essentially impossible to patch a flaw should it become discovered without waiting for each vendor to update their enterprise software to support the new JVM.
In the end, the network security guys threatened to pull the machine off the network unless we could replace the faulty JVMs, so we just gave up on using Java. It was just an evaluation, and there are other solutions out there that don't cause the security problems Java does.
...at least we can be assured whatever disaster happens, it will happen slowly. Just kidding!
That's what makes it a joke, for all those who've actually read the license agreement. :-)
If this is about the buffer overflow in JNLP ("Sun Java WebStart JNLP Stack Buffer Overflow Vulnerability"), then the fix has already been released with JRE 5 Update 12 and the latest JRE 6 update.
It's like Windows!
Non free FUD wars are so entertaining. The war on Java will get twice as hot now that Sun is freeing it. ZDNet won't know if they should call it Dangerous or Cancer.
Friends don't help friends install M$ junk.
The alert is accessible at http://www.auscert.org.au/render.html?it=7664.
Not sure what all the noise is about. The security "experts" from penetration testing firm Pure Hacking are twats for blowing this all out of proportion.
*blinking cursor*
This issue (I'll provide a link to the AusCERT page as the summary neglected to) was first publically announced on June 4 and fully patched by June 29th. All that's happened recently is some minor updates to the ticket. Yes it's serious, but anyone paying attention to such things will have patched already.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
I wonder if this affects IBM's J9 in any way?
x86, oh yes, I'm pro.
It's probably Security Vulnerabilities in the Java Runtime Environment Image Parsing Code May Allow a Untrusted Applet to Elevate Privileges, which sounds like a flaw in native code that loads images.
.NET uses more native code than Java so one would expect similar kinds of bugs to affect it.
Note that this kind of vulnerability can happen in anything using unsafe code. It is not an indictment against Java's security model, it's just a bug in the native code libraries used to make the implementation faster. Also
This kind of problem will not exist once all of our libraries and operating systems have been written in safe languages such as Java.
I'm pretty sure my shoes and coffee mug are going to make it through this ordeal.
You coffee mug is especially vulnerable to java.
I can also see where this vulnerability might extend to your shoes, especially if you are standing, holding a coffee mug with java installed, and there are other java users moving around you.
paintball
Well said!
How are my JSP/Servlet servers affected by this? Even if i was running the most unsecure version of java, I choose what code runs on them. People don't use the server's vm to execute random applets from the internet.
moi
In Firefox will it help to at least uncheck Enable Java in /Options/Content?
Just because you are paranoid doesn't mean there isn't an invisible demon out to eat your face.
wtf does your comment even mean?? knowing the mods around here though, you'd probably get modded insightful or something equally stupid.
I find this an extremely hard story to swallow, especially given the lack of details in the article. I'm surprised this story even passed Slashdot's screening process.
I think you can leave Javascript enabled, just turn off Java. I think the only time I've ever had Java enabled anyways was to play Yahoo games.
Having Java enabled has a usefullness/security-vulnerability ratio almost as bad as ActiveX.
You see? Had this been Open Source intsead of Open Sores, this would not have happened.
Just disable Java outright in Firefox by going to the Content section of Preferences. Then you don't have to wait 10 seconds if you happen to hit a page that uses Java.
Have you got any proof that ZDNet shills for Microsoft, or are you just making up prize bullcrap as usual?
According to the AusCERT report the bug is in the image parsing code. So if your Servlet somehow accesses images being uploaded or residing on a third party server, it is vulnerable.
In that case, the attacker might be able to run any executable on your server.
No, as others have pointed out it's a flaw in JPEGs and BMP files. PNGs (pretty much the only format used in J2ME in cell phones and PDAs) are safe. Here are the advisories:
http://www.auscert.org.au/render.html?it=7664
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
The biggest concern is that arbitrary applets could be pushed to user's machines. This is mitigated by the fact that the latest JVM's have already been repaired. Thanks to the Java autoupdater, there should not be many desktops at risk.
A secondary concern is servers that accept image uploads. BMPs are usually not accepted anyway, but JPEGs could be a concern. So it is best to upgrade these. Which brings us around to your concern...
For one, it is possible to upgrade these JVMs. It's a bit trickier than a standard install, but it can be done, at least inside the same VM version. (e.g. Java 1.4 apps will usually not suffer from an upgrade to 1.4.1, but a Java 5 upgrade would be disasterous.)
Secondly, I *DO* have a solution. Yell at the vendor! If they're going to stupidly integrate the JVM for no reason other than to make your life difficult (ostensibly to make it easier, yeah right) then they can take the burden of getting you a patch. Don't let the vendor off the hook until they get the problem fixed! That's just good practice, nothing to do with Java.
(Of course, a better practice is to find a vendor who doesn't stupidly integrate JVMs, but I digress.)
BTW, are you talking about Oracle AS or Oracle Database? Oracle AS would need to be patched for situations like this just in case you handle or will handle image uploads. Oracle Database would not be at risk since there is almost no chance of the database being made to parse images in its procedural code. Desktop applications are similarly unaffected unless they download arbitrary images from the internet.
Javascript + Nintendo DSi = DSiCade
Write once, pwn anywhere!
Uhh yeah, and while you're at it, disable flash, java, and just use a text browser like lynx. Who needs all this web 2.0 content anyways. I mean does anyone actually enjoy watching youtube, using Google maps, using zillow.com or chatting through a web interface or going to sites that use javascript like slashdot?
No Sigs!
Oh wow, that sounds really scary. I really wouldn't want to be in the Enterprisey world. I mean, they don't seem to have apt-get there. Or any of those mass-update tools in Windowsland. And they disabled that Java Windows autoupdate thingy because, well, who needs that?...
FUDdy, huh?
This proves two things:
a) a virtual environment is as secure as its host.
b) it's time to stop using C.
(the above is valid if the flaw is in JNLP and/or ICC handling code, as some posters said).
Google team reports an AusCERT find? AND no details? A simple sentence saying what the error is? Is it patched?
Sounds like someone saying "Mission accomplished" w/o showing any proof--sounds like FUD.
....theres a reason why the problem with the JVM is not described. If it was, every cracker would be able to write an exploit pretty damn pronto!
My web domain.
Well, I can see why you can't say "Do this, this and this and behold, a buffer overflow. Now here and here some code and presto, code injection".
But this article reads kinda like a mix of a homeland security threat warning and a political speech. There's some kinda-sorta threat, and we deem it critical, and all hell breaks loose if someone steps into it.
What kinda "information" is that? The link to the actual information has been posted before (yeah, yeah, mod me redundant, my karma will soak it), but could we PLEASE get submissions that actually contain links to some info? I mean, I'd already be happy with some slander and propaganda, but I'm feverishly against a waste of bandwidth like the linked article.
Think of us commenters! How do you think we should comment if there's nothing to comment on?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Doesn't matter. The computer security people install software on all network-connected PCs that scans for vulnerable software. If it finds a vulnerable JVM, they'll make you patch it or move the machine offline. Even if it doesn't make sense.
Like the article said, trying to upgrade Java in the enterprise is nearly impossible. The place I work uses the solution of forcing the issue by scanning the entire filesystem for vulnerable applications, which includes JVMs.
So what is all the excitement about!?
1) Thís is a buffer overflow error (i.e. an implementation error) in Suns JRE (not in any other vendors Java; IBM and others seem to be safe).
2) It is an overflow in the image library, so it is unlikely that this will affect mobile phones, PDA's and other hard-to-patch devices.
3) There is a new, patched, release available for every affected platform and for every affected java version.
4) Buffer overflow errors (similar or worse than this) which need to be patched, are detected if not daily then at least weekly in the most commonly used operating system on this planet.
What is the big hype about?
Is Java becomming too popular? Is this a FUD campaign?
Dude, evaluate words in context. "Everything" implicitly means "everything that we're talking about." If I go into a football huddle and say "everything's at stake in this next play" everybody knows I mean the game and nobody infers that dropping the ball means the end of the universe.
Your alternative headline ("everything virtual") implies that only Java software is affected. Which I hope is not what you meant. I haven't seen a proper description of this exploit, but if it allows the attacker to inject native code into the target, then everything on that computer is affected. And to an IT director, computers are everything.
I'm not faulting you for nitpicking. That's what I do for a living. But not all nits are worth picking.
"This kind of problem will not exist once all of our libraries and operating systems have been written in safe languages such as Java."
I guess that will happen when all computers use a Java processor so there's non-Java native code.
``even though the browser may be fully patched, some people neglect to also patch programs invoked by browsers to render specific types of content''
No problem. When you do apt-get upgrade to install the latest, patched version of your browser, it also updates all your other software. Wait! You _are_ using an operating system with a proper package manager, are you?!
Note that I'm saying this not to flame anyone's operating system or to assert apt-get's superiority, but simply to drive home a point I've made before: when security depends on keeping software up to date, it's only as good as your maintenance. Sadly, many operating systems make this kind of maintenance tedious and time-consuming. This basically leads to a choice between (1) an insecure system and (2) high maintenance cost.
I use Debian, which makes keeping software up to date a breeze. There are other systems that do so. Sadly, there are also many that don't, including some very popular ones.
Please correct me if I got my facts wrong.
Im suspicious.
``they really work only with the specific JVM shipped), so you're left with vulnerable JVMs and no way to upgrade them.''
And this, ladies, gentleman, scum, and bots, is why portability is important to security.
Please correct me if I got my facts wrong.
Ubuntu has Sun Java packages available (not installed by default), so you can get automatic updates with that. I don't know if Debian still has those packages in non-free, but when Sun JDK/JRE 7 come out (GPLv3), they should be included in main. Gentoo has an ebuild for it already, so just hope that the ebuild gets updated as usual. I don't know about the Red Hat family of distros, but they're probably covered just as well.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
Yeah boy! Text browsing rocks! You haven't lived until you've seen YouTube's Top 100 in the original ASCII.
No. Seriously. Check it out. At least it will give you something meaningful to do at work. You can include it in your section "How to waste time on meaningless activities"* in your new Project Management book (see blog link).
* Also known as how to make your computer illiterate boss millions of dollars while he plays golf.
So what's the problem again?
Watch this Heartland Institute video
Dangerous Java Flaw Threatens 'Virtually Everything'
I figured it wouldn't be long before a stupid software bug came along that would threaten the very existence of the universe itself. I knew it!
I'm still using the old Microsoft 1.1 JVM. That should be safe, right? ;-)
It's just the Sun JVMs with problems...
>> (Of course, a better practice is to find a vendor who doesn't stupidly integrate JVMs, but I digress.)
6 82/37682.html?Ad=1
Actually, Microsoft was required to integrate Sun's JVM in their operating system because of their efforts to undermine and corrupt the Java Standard.
http://www.windowsitpro.com/Articles/ArticleID/37
Maybe MS will update (cross my fingers, its an uninstall) their POS 1.1 spec JVM, that to this day causes headaches and frustration at my workplace.
The problem is that once you find the vulnerable JVMs, you can't actually patch them because the software has some bogus requirement that you don't change the JVM.
I'm not entirely sure why or even how they manage to do that, but they do. So you're left with either removing the offending software (since it has a vulnerable JVM) or living with the vulnerability, which IT won't allow.
I clicked on the update tool and it shows an update to Java 1.5. The description says:
/dev/tty,
Update Version: 3832-0
Category: Security
Status: Needed
The Sun JAVA JDK 1.5.0 was upgraded to release 12 to fix
various bugs, including the following security bugs:
CVE-2007-2788 / CVE-2007-3004: Integer overflow in the
embedded ICC profile image parser in Sun Java Development
Kit (JDK), allows remote attackers to execute arbitrary
code or cause a denial of service (JVM crash) via a crafted
JPEG or BMP file.
CVE-2007-2789 / CVE-2007-3005: The BMP image parser in Sun
Java Development Kit (JDK), on Unix/Linux systems, allows
remote attackers to trigger the opening of arbitrary local
files via a crafted BMP file, which causes a denial of
service (system hang) in certain cases such as
and has other unspecified impact.
CVE-2007-0243: Buffer overflow in Sun JDK and Java Runtime
Environment (JRE) allows applets to gain privileges via a
GIF image with a block with a 0 width field, which triggers
memory corruption.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
We note that this vulnerability happened in a C library that was used for processing images. There wasn't a buffer overflow in the Java portion because Java has no buffer overflows. It's in the C code where buffer overflows can lurk for years and years.
They should be looking at all these areas and trying to move to all-Java implementations for as much of the code as possible. And yes, it should be possible to write a Java implementation of a JPEG encoder and have it run as fast as the C implementation.
I just got done installing Java in 3 computer labs, and took the extra step of turning off that damn annoying autoupdate feature in the Java Control Panel on every machine. Crap, there goes my weekend...
I am not left-handed, either!
Am I the only one who originally read this as: Dangerous Lava Flow Threatens 'Virtually Everything'?
"Evil will always triumph over good, because good is dumb." - Dark Helmet (Spaceballs)
This is the first buffer overflow vulnerability Java has ever been found to have, AFAIK. And they announce it with "threatens nearly everything." Don't the buffer overflow vulnerabilities announced frequently about IE and other programs also threaten nearly everything?
It seems that the favorite thing for both lefties and righties to do is to eschew an interpretation of the Constitution which suggests that it grants citizens rights. Strict Constructionalism and the Living Constitution Theories are both flat out wrong, and both sides are wrecking the country when they twist this document for their own political causes.
Madison, who wrote the document, along with everyone that passed it, saw that the Constitution grants the -government- some limited rights, with the assumption that the people have ALL the rights, and thus, we as a people are allowed to do anything that is NOT in the Constitution or, made illegal by the government in some limited way.
To wit, any reasonable court that actually cared about the Constitution would throw out a vast majority of federal statutes, left wing or right wing, largely because the only thing the federal government is allowed to do is roughly:
a) declare wars.
b) make copyrights and patents, manage highways, and the mail.
c) make laws to regulate commerce.
d) tax income (16th amendment)
Anything else, from acts restricting gay marriage, to acts restricting guns, are simply unconstitutional at the federal level, as would be wiretapping, surveillance, environmental and some civil rights legislation (that which couldn't rest logically on the equal protection amendment, or the commerce clause). So affirmative action and reparations are illegal, but sending in the feds to bust some heads because of cops lynching a guy is legal.
Bottom line is, if you argue that someone doesn't have the right to do something, because it is not in the constitution, you have missed the boat on what the document is all about.
This is my sig.
And no chairs were thrown in the production of this snippet.
/\/\icro/\/\uncher
So if your JVM includes a JIT, it is not so farfetched for it to be "pure" Java. (The privileged bytecodes are an extension to the Java standard.) Such a design eliminates whole classes of common bugs. Unfortunately, there are infinitely many additional classes of bugs to take their place. One reason why production JVMs are still coded in C is that the code generation of mature C compilers is so much better than a first generation JIT.
No reference to which version, no nothing.
This sounds like FUD or fear mongering with no facts at all.
Rumor mill.
The closest thing to this I have found is on the early access Java 6 SE and IIRC has been patched already!
Which means, a full release cycle. Most enterprises (a catch-all phrase that usually maps to the largest corporate environments, involving thousands of employees) support a range of in-house and 3rd party applications, utilities and infrastructure tools. QA on a release cycle for desktops can cost hundreds of thousands of dollars in employee time and delayed projects, but to perform the release any more cavalierly can result in even more damage.
How does this differ from any other security patch? It's not because Java is ubiquitous - the components that are patched by many security fixes... particularly from companies like Microsoft and Adobe... are even more widely used. How do you roll out security fixes now? Or do you just not bother to keep up to date?
If you have multiple Java versions on your computer and/or you do not know which version is used by your browser, try this page:
http://www.javatester.org/version.html
According to AusCERT, http://www.auscert.org.au/render.html?it=7664
you are vulnerable, if your JRE is:
- Sun Java Runtime Environment (JRE) 6
- Sun Java Runtime Environment (JRE) 5.0 Update 10 and prior
- Sun Java Runtime Environment (JRE) 1.4.2_14 and prior
- Sun Java Runtime Environment (JRE) 1.3.1_20 and prior
I know you get the JVM from Apple on Macs. I tried to compile the example code from http://scary.beasts.org/security/CESA-2006-004.htm l but it failed with this error:
$ javac ImgReader.java
ImgReader.java:15: incompatible types
found : java.lang.Object
required: javax.imageio.ImageReader
ImageReader reader = it.next();
^
1 error
I was going to try the sample JPEG on it. I don't have time to fiddle with this, maybe someone else can try it and see what happens.
Debian also has Java packages in the repos (in libs/non-free).
No problem, we modify this problem in
http://icedtea.classpath.org/wiki//Main_Page
http://en.wikipedia.org/wiki/IcedTea_(software)
Will it be solved?
What lines are to be modified?
Else, "to reinvent the VM with a good isolation".
Really, could an article be less informative than this one?
This hole might have been a bit easier for Sun to patch if they hadn't made the automatic updater, jusched.exe such an unstable and annoying piece of junk. Or if they made updates work at all. My JRE is still beta 2 and has never seen an update since.
Screw it. I run Windows anyway, it's not like my system isn't already full of holes. What's one more?
Done with slashdot, done with nerds, getting a life.
Secondly, I *DO* have a solution. Yell at the vendor! If they're going to stupidly integrate the JVM for no reason other than to make your life difficult (ostensibly to make it easier, yeah right) then they can take the burden of getting you a patch. Don't let the vendor off the hook until they get the problem fixed! That's just good practice, nothing to do with Java.
It's not about integrating the JVM. It's about operating with a newer one, where some piece(s) of code operated normally under 1.x, and don't operate normally under 1.(x+1)
This occurs whether or not the JVM is rolled out with the APP or a separate install.
You have to have native code implementation of some methods, at some point.
:)
I have to admit that I have been very impressed by the overall security of Java. The design is not inherently safe, so the implementation has to be flawless, and I was extremely skeptical of this approach... but Sun has done an excellent job of implementing the Java security model in Java itself with untrusted code running in the same fully capable virtual machine as trusted code.
This means that for untrusted code, implementing as much as possible in Java is the most secure way to go. And avoiding native OS- or application-specific extensions (like, for a recent example, animated cursors in Firefox) keeps Java from being a carrier for indirect attacks.
There are, however, some caveats:
First, for trusted code (for example, normal applications) avoiding native libraries has a potentially huge performance cost. I'm not talking so much about the overhead of Java itself, but portable OS- and application-independent code can't take advantage things like a native graphics API that's directly mapped to GPU operations. I'm sure you can call OpenGL from Java, but I would hope that you can't do it from a Java applet - so applications should perhaps not be held to such a strict regimen.
Second, one of the problems with Java as a "run anywhere" language for applications is that so much of Java is implemented in Java, emulating a Windows style user interface (I don't have a problem with Sun choosing Windows here, that's where the market is, but it does make Java less attractive to people wanting to "run anywhere".
Third, solving this problem for Java may be less useful when it comes to security than fixing the native libraries so they're secure whether they're called from Java or some other component for the display of untrusted content (like a browser).
The flip side of this last point is that implementing a good browser purely in Java would seem to be a way to avoid that problem... but the catch-22 there is the first and second problems, plus so much of the web now *depends on* plugins like Flash, media players, and even Java itself.
A buffer overflow in images that only affects desktops and servers supporting image uploads
According to the announcement, it allows applets to elevate their privileges.
Bunch of FUD-spreading fear-mongers. Hrumph.
If applets are vulnerable, that's not FUD, it's serious. Of course, it's only the latest in several such vulnerabilities over the years, which is probably why many people just disable Java.
Oh, and Sun wouldn't have had this problem if they'd used pure Java code rather than relying on an existing library.
Yes, that would be the right thing to do. Unfortunately, Java sucks for writing that kind of code.
I've seen a lot of pages describing this vulnerability, but I'm still not clear on what APIs are involved. You are one of many who have said it's probably in native code, which makes sense, since the Java runtime won't permit a buffer overflow in Java bytecode. Can anyone confirm if this means the vulnerability lies in Applet.getImage, Toolkit.getImage, Toolkit.createImage, and certain ImageIcon constructors, while the loading of images through ImageIO is unaffected?
The Internet is full. Go away.
Yeah, but you didn't answer his question. Could it be because *you're* the one on Microsoft's payroll, tasked with making the FOSS movement look like a bunch of deranged lunatics?
In my experience LISP programs are some of the easiest programs to understand.
I love how in the past ten years, LISP has been bashed because of a few parenthesis and XML has been lauded for its angle brackets.
The two forms of expression are isomorphic.
I'm only guessing, but I believe this vulnerability directly relates to ImageIO. The Toolkit only supported the load of PNG, GIF, and JPG the last time I checked. This vulnerability has to do with BMPs and ICC profiles in JPGs and BMPs.
Javascript + Nintendo DSi = DSiCade
Right, trying to explain this to the CS crowd...
Soviet -> Microsoft
Chernobyl's RBMK reactor -> Windows ME
IAEA -> Open Source Movement
European Pressurised Water Reactor -> OpenBSD, default install
Yes, hardware can fail, but depending on how you build it the probability of failure, and just how damaging a failure will be, will differ greatly. So just like any sane software developer will not build a system where a bug in your animated cursor rendering is likely to allow execution of arbitrary code, a modern western reactor is not built in a manner that lets a bug in a LISP program cause a complete meltdown. Much has changed since TMI. Modern designs have redundant safety systems for virtually every critical part of the reactor. As an example, Canadian reactors have multiple redundant sets of control rods. Some are manual, some are automated , and the automated ones are split between two separated systems. Triggering any one of them will cause complete shut-down of the reactor, and should all control rod systems fail it is possible to inject neutron-absorbing substances into the heavy water moderator, triggering a shut-down that way. Now, I'm not going to state anything for certain, but if you can come up with a bug in a LISP or Java program that would defeat such a system, then quite frankly I have to wonder what you are doing speaking to us mortals ; - )
I realize you weren't serious about giving up everything, but how about at least having some text-only POP and web email clients to avoid html vulnerabilities and web bugs (AKA Yahoo Web Beacons) when browsing mail? (names of OS X and Linux versions needed)
Perhaps Firefox ought to have a plain text mode for all but trusted sites?
Giving up rich content for browsing is one thing, but most of the time there is no need for it in email.
Text content with support for file attachments would be plenty.
Can anyone explain why Sun changes the name of the package with every minor version?
J2SE Runtime Environment 5.0 Update 11
Java(TM) SE Runtime Environment 6 Update 1
Java(TM) 6 Update 2
What will the next update be called? J2SE Runtime Environment 6.0 Update 3?
Installer changes every time, too. It is just inconvenient for those that want to do unattended installs.
I liked him in St. Elmo's Fire and The West Wing, also the Mike Meyers/Dana Carvey movie,
but how is he qualified to speak about Java security flaws?
So, Google's security team found the flaw in Sun's java JRE ... Isn't that like Microsoft's security team finding bugs in Apple's or IBM's code?
libertarian: (n) socially liberal, financially conservative; neither left, nor right.
Didn't he make a porno a decade back?
No offsense, but that's a rather incredible claim. They're saying that no matter if you're running a JVM on the server, cell phone, applet, desktop, or just about any other environment, you're vulnerable? I'm sorry, I can't accept that without extraordinary proof to back up such extraordinary claims.
No extraordinary proof necessay. Java's original slogan is write once, run anywhere. So generally speaking, a program that runs on your server can also run on your cellphone, desktop etc. And (again genrally speaking) that program will have the same bugs on all of those environments. Of couse this is a JVM issue, but you get the picture.
Java was designed from the beginning with security in mind. Its security infrastructure has been tested for over a decade now.
This doesn't really have anything to do with security infrastucture. It's a vulnerability in the image parsing code.
Reliability analysis is used to quantify failure rates. It is poor practice to use logic to analyze either a computer program or a safety system. Logic can only reveal the obvious flaws in the system. Logic does not help us to quantify the impact or severity of the flaw. Logic assumes things "always" happen. Real-life does not "always" happen as intended. Mechanical systems are never "always" consistent. Computers aren't "always" consistent either. Users have a big impact on problem severity.
We have 100+ years of history designing mechanical systems for applications were they almost "always" work. This gives us ample data to quantify likely failure modes. These failure modes can then be analyzed and prevented by other safety measures.
In the case of safety systems, layer upon layer of checks are present. The concept is that even if something fails, or comes close to failing, it will be picked up by another check. Quantifying the performance of a safety system is not about logic, it is about reliability analysis. How many failures are likely to happen? and how many failures does it take before something dangerous happens?
One report on 3 mile island listed separate 114 (?) failures that ultimately resulted in the core meltdown. How unlikely is this? Mathematics tells us that unlikely events happen all the time. Every day someone wins the lottery. How unlikely is a nuclear accident to occur? That question is answered by reliability analysis, and it is a complex field including both statistical techniques and logic.
How likely is it that something bad will occur as a result of this Java bug? It turns out that the computers (and their users) would have to make thousands of poor decisions before suffering adverse effects from this bug. Unfortunately, millions of computers exist, each making millions of decisions per second, so some people will probably be affected. Quantifying the severity of the problem is a difficult reliability analysis problem.
"Run everywhere, run anything"
Table-ized A.I.
No Java for me, unless it's in a cup. I stick exclusively with ActiveX- it's way more secure. Obviously.
The only thing Java has given me in the past few years has been viruses. It's kind of incredible how many network-aware Java viruses there are, and how little press they get. That's FOSSies for ya!
Ok, apparently you're not getting this. Java was created to prevent security hazards like this by design. Which means that if there actually is a "Write Once, Run Anywhere" vulnerability in Java, it's a massive flaw in Java's design.
It's possible that such a flaw could have been found 10 years ago, but at this point its security has been tested by fire. There's no way to pierce the veil of Java's security design. Major flaws are further down the pipeline in the implementation of the JVM, which means that (by definition) the flaw does not exist on all JVMs.
As it turned out, this is a flaw in the implementation of the JVM. Someone linked in native code where it probably wasn't a good idea to do so. In result, desktops and some servers are vulnerable. (Actually, very few are thanks to Java's autoupdater which has already upgraded most machines to a fixed JVM.) This hyperbole about PDAs, Cell Phones, etc. is exactly that: Hyperbole. These devices are NOT vulnerable. It's just some analysts lame attempt to extend the issue where it isn't because he doesn't understand the problem in the first place.
And THAT is why I shouted that it required extraordinary proof. Not because it ended up being a fairly textbook bug in native code, but because of the article's extraordinary claims of all JVMs being affected.
Again, extraordinary claims require extraordinary evidence. The article made extraordinary claims and was unable to follow up based on the evidence at hand.
Javascript + Nintendo DSi = DSiCade
J2ME can support jpeg as much as png's. You were misleading in this. But you are also right... since the api just care about loading images it's the vendor's task to implement which formats will be accepted by the device (in other words... you may not need any decoder at all). The coder only need to deal with the bitmap (array of pixels) resulting from the file load.
I think you need to qualify that a bit more. The vast majority of server applications that accept image uploads treat the image as a stream of bytes that they save to a file or database. To be vulnerable, they have to actually decode the image using the vulnerable parser, which is not a trivial thing to do unknowingly on a headless server.
But you are correct. If you just have a simple file upload with no parsing, you'll be just fine.
It's not trivial if it's truly headless. Java has had headless support for a while now that is capable of doing graphics even without a graphical system running. The only way that it absolutely doesn't work is if you have absolutely no X11 libraries in your path. Windows and Mac machines will always work.
Also, you don't actually need to modify the image to trigger the vulnerability. If you parse it at all you will trigger the exploit. The image IO libraries are not dependent on a graphics library and will work on a truly headless server. So if, for example, you change all BMPs uploaded into PNGs for storage, you may be in need of an immediate update to your JVM.
Javascript + Nintendo DSi = DSiCade
... executes code on the stack? buffer overflow vulnerabilities are the result of Intel Idiocy and the legacy of programmers who exploited the flaw to write l33t self-modifying code that resulted in "backwards compatibility" keeping us vulnerable even after they the default and not a particular language.
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
I can't comprehend why people continue to use platforms without package management, or why there has never been a serious project to bring a package manager to these other platforms.
If it was a large office full of, say, Linux desktops, which ran a nightly update off some repository stored in the office, then you just update that repository. If it breaks something, you roll back, or roll out a new patch to fix what it broke.
Maybe not easy, but certainly no harder than rolling out patches to a small or medium-sized office.
Don't thank God, thank a doctor!
Everytime I try to download the patch, I get an invalid file, an HTML document instead of what I should be getting. Sun can't even keep their crap up and running.
Bryan
FUD FUD FUD.
Its really bad and we'll never get it patched!
FUD.
Slash Blackmail
'Virtually Everything' ~telengard
Until recently, even the best possible pure Java JPEG implementation would have been a lot slower than the C implementation. "Java is slow" used to be true. Sun's decision made sense when they made it. It doesn't make sense anymore. With the state of JIT, a Java JPEG library would be running as native code, just like C, and would be as fast or perhaps faster.
------------
My IP address
Vista Internet Explorer's "protected mode" really helps cut the impact of possible attacks, but (similar to Java) Flash provides an avenue of attack because it runs outside protected mode. IE on Vista pops up a dialog asking for approval to run a component (i.e. Flash) outside of protected mode.
Unfortunately this security measure is pretty useless. This is because if the user leaves the "don't ask me again" checkbox unchecked so they can confirm each elevation, they may get 10 or more prompts when a page loads because so many pages and ads use Flash in multiple places and each one is prompted for separately, and the user isn't given a good indication as to which one is prompting. The only way to avoid being bombarded by popups it to check the box, but then the user is never asked and Flash is elevated without warning on all web sites, resulting in a much bigger security issue when a Flash vulnerability is found.
To make this better, Microsoft really needs to:
- clearly identify the URL (and filename?) of the Flash object in the prompt since it may be different than the web site being visited
- store the "do not prompt" option per-website and provide a way to manage the list of approved sites
As much as people here refuse to stare a Microsoft product in the face and realize something good about it, IE 7 protected mode will substantially limit the effect of this vulnerability. Note that the OS features it employs to reach this are also available to other browsers, who have for some reason not implemented it.
Unfortunately packages in contrib and non-free do not receive security updates, which is worse than if the packages did not exist in the first place: anyone running etch who installed the packages, expecting them to be updated is now screwed.
http://bugs.debian.org/431831
According to the security bug tracker, etch's java package is vulnerable to CVE-2007-2435, CVE-2007-2788, CVE-2007-2789, CVE-2007-3004, CVE-2007-3005 and CVE-2007-3503. No security updates are planned for any of these issues.
Might want to check out Appupdater. It 's like apt-get or yum but on Windows, or Windows Update but for all the random apps on your computer. Will keep them up to date and using the latest versions with security fixes, and can be run on a corporate network.
http://www.nabber.org/projects/appupdater/
Java updates have side effects sometimes, like browser reconfiguration.
So can any security fix. Hell, there's some whopping design flaws in the Microsoft HTML control that *will* break software if Microsoft ever gets the balls to fix them, and they *have* broken stuff with security patches before.
The point is, if people are holding off security fixes because they're worried about a patch to an image reading library in the Java runtime having unintended consequences, how do they ever summon the courage to perform ANY security patches.
Or do they just not apply them?
That would help explain the "robust viral ecosystem" out there.
Or at least, it distributes the process.
Let's say VB was distributed using a good package management system. (I actually think all of them suck in subtle ways, and I may write my own sometime, but I digress. Assume for the moment it's good enough.)
And let's say all of the VB software you run is distributed with the same package management system.
Minor VB updates are things that should not possibly break anything, except badly-written software. If the software is being developed by people who also use a package management system, chances are they can't get away with anything that depends on exactly version 2.3.5 build 81345 or something, because it would constantly be breaking their stuff in development. But if they behave, then they should be OK until version 2.4.
Then, version 2.4 comes out, and the developer of software depending on version 2.3.5 test their stuff with 2.4, patch it if needed, and roll out a new package that depends on 2.4.
Linux distros, in particular, are usually set up in such a way that multiple versions of a library can be installed without conflicting with each other. So, our hypothetical package manager would install the new, updated library, and when all your apps have been tested to work with that version (by their respective vendors, not you), then the dependency on the old library is removed and it's cleaned out with the next reverse-dependency clean.
Also, package management would tend to make it easy to uninstall a package, or roll it back, in a worst-case scenario. These are not always easy on Windows, and not always possible, especially with something like VB or IE -- with Windows, I'd take disk images.
I'm not saying the problem becomes always trivial in all cases. A major glibc upgrade on Linux probably breaks more things than a VB upgrade on Windows. But a package manager does make it trivial to at least track what you're doing -- that way, your system knows exactly when the glibc upgrade is allowed.
Don't thank God, thank a doctor!
You're still creating an artificial distinction.
A change to a library routine that's used to read an image file is a change to a library routine that's used to read an image file.
It is *more* likely that this will effect "all your software" if it's a change in a commonly used component than if it's in a component that just happens to be part of a runtime for a language that some of your software uses.
Also, I wrote "Yes, the vendor could sneak in other patches, but that's no different to *any* other patch from *any* vendor that provides a language runtime". I didn't mean "any patch to a language runtime" from such a vendor, I mean *any* patch from such a vendor.
For example, *any* patch from Microsoft might change MSVCRT, so you shouldn't casually roll out *any* patch from Microsoft lest it break every program written in Visual C.
I'm saying that any patch that is going to affect diverse development teams' work, across the entire organization is going to have to go through an expensive rollout process, and that's the unfortunate reality that people in large enterprises have to live with
That means, *any* patch from *any* vendor that makes *any* software that your developers are likely to depend on, whether it's a patch for that software or not, is a "patch that is going to affect diverse development teams' work". Any of them.
So DO you roll out security fixes at all? How do you justify it?