| Summary: | dev-java/sun-{jdk,jre-bin} : multiple vulnerabilities | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | java, kfm, mmokrejs |
| Priority: | Normal | Keywords: | PMASKED |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://secunia.com/advisories/53846/ | ||
| Whiteboard: | A1 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 483018 | ||
| Bug Blocks: | |||
Increased importance to critical according to other bug #473980. Since there were no newer versions in branch 5 [1] and branch 6 [2] I would like to last rite this sun-jdk and sun-jre-bin, we are unable to patch this because it is binary; however, before I can last rite these packages we need to sort out some packages that depend on this: mattm: =media-gfx/replicatorg-{37-r1,40} Could you try to see if you can rdepend on the virtual or oracle-jre-bin? video: =media-video/aacskeys-0.4.0c Could you try to see if you can depend on the virtual or oracle-jdk-bin? java: virtual/jdk, virtual/jre Can I proceed to drop sun-jdk and sun-jre-bin from the virtuals? java: =dev-java/xmlgraphics-commons-1.2, =java-virtuals/jdk-with-com-sun-20111111 Someone needs to try these with the virtual or oracle-jdk-bin. [1]: http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase5-419410.html [2]: http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html + 29 Jun 2013; Tom Wijsman <TomWij@gentoo.org> +jdk-1.5.0-r1.ebuild, + +jdk-1.6.0-r2.ebuild, -jdk-1.5.0.ebuild, -jdk-1.6.0-r1.ebuild, + -jdk-1.6.0.ebuild: + Remove sun-jdk and sun-jre-bin from the virtuals, acked by Caster. For + security bug #473830 reported by Agostino Sarubbo. + 29 Jun 2013; Tom Wijsman <TomWij@gentoo.org> +jre-1.5.0-r2.ebuild, + +jre-1.6.0-r1.ebuild, -jre-1.5.0-r1.ebuild, -jre-1.5.0.ebuild, + -jre-1.6.0.ebuild: + Remove sun-jdk and sun-jre-bin from the virtuals, acked by Caster. For + security bug #473830 reported by Agostino Sarubbo. + 30 Jun 2013; Tom Wijsman <TomWij@gentoo.org> + +xmlgraphics-commons-1.2-r1.ebuild, -xmlgraphics-commons-1.2.ebuild: + Remove sun-jdk and sun-jre-bin from reverse dependencies. For security bug + #473830 reported by Agostino Sarubbo. + 30 Jun 2013; Tom Wijsman <TomWij@gentoo.org> -aacskeys-0.4.0c.ebuild: + Remove sun-jdk and sun-jre-bin from reverse dependencies. For security bug + #473830 reported by Agostino Sarubbo. + 30 Jun 2013; Tom Wijsman <TomWij@gentoo.org> +replicatorg-37-r2.ebuild, + +replicatorg-40-r1.ebuild, -replicatorg-37-r1.ebuild, -replicatorg-40.ebuild: + Remove sun-jdk and sun-jre-bin from reverse dependencies. For security bug + #473830 reported by Agostino Sarubbo. + 30 Jun 2013; Tom Wijsman <TomWij@gentoo.org> package.mask: + Sun JDK and JRE contain critical vulnerabilities and receive no further + updates; masking to make users aware of this, users that still need this + package and have no alternative can unmask at their own risk. See bug #473830. Done, decided to mask the affected package instead. We can't really last rite it because there are reverse dependencies outside of the Portage tree as well as applications that don't come from packages that rely on this, and no alternative implementation is possible. Users that really want to run it despite the critical vulnerabilities can then choose to unmask the package, at their own risk. > Done, decided to mask the affected package instead.
Thanks, I approve of this decision. I work in a Java shop, where the Oracle/Sun runtimes are mandated for various (valid) reasons. We are well aware of its poor security track record but very few - if any - of the listed vulnerabilities are relevant to our use case; nor is it practical to switch runtimes at the drop of a hat. Hence, to drop the packages outright would put Gentoo at a disadvantage in environments such as ours - a situation that would be saddening. I would also point out that neither Java 6.x nor 7.x are EOL. I hope that this is borne in mind when situations such as these arise.
(In reply to Kerin Millar from comment #4) > I would also point out that neither Java 6.x nor 7.x are EOL. 7.x is indeed not EOL, but I didn't saw an update for Java 6.x to patch this so I assume it is EOL; if you do see an update, feel free to let me know. There is a Java SE 6 Update 51 but, unfortunately, it's not being distributed through public channels (ridiculous, I know). I retract my remark concerning 6.x as it is effectively EOL for the general public. In case anyone cares, here's the sha256sum for Java 6u51: 8e537eeb540878c83d98ca7d884aadb8ea956658b1511d1c316632ae4f7e3b26 *jdk-6u51-linux-i586.bin That's generated directly by myself and can also be corroborated by the PKGBUILD in the AUR (Arch User Repository). I haven't looked at this in detail but I understand that it resolves the mentioned vulnerabilities. It appears that Oracle is only releasing patch version 51 to people on enterprise support contracts, and is generally using this to EOL Java 6 and make people upgrade to 7. GLSA vote: yes, issue at least a temporary GLSA but leave it in tree. @Java team: your thoughts? How long do you all want Java 6 to remain in the tree? For users not much familiar with java the message referring to this bug number from package.mask file should give a *hint* what other package is believed to be a good replacement. I use an application which needs dev-java/sun-jce-bin. Will that work with say ibm java? Or will there be something working with ibm-jre-bin ibm-jdk-bin? (In reply to Martin Mokrejš from comment #9) > For users not much familiar with java the message referring to this bug > number from package.mask file should give a *hint* what other package is > believed to be a good replacement. Unmerging them will give a replacement; we can't judge what is good for you, yet there is a default in place because it is listed first (that is oracle-*). We cannot judge what would be a good replacement; so, I'm not sure if we should do that. From what I recall only one other user has shortly wondered about this in #gentoo; so, maybe there is a need to change it. But I'm not sure to what, suggesting people not to use something is safer than suggesting people to move to something; after all, Gentoo is about choice. So, the question would be, how do we present the choices in a sane way? I have no idea of a clean short command that would list them, preferably without any extra tools; so, feel free to suggest one or otherwise I might look into it. I'm thinking some short python call might list what satisfies a virtual; so, I guess we could look that way. Although I am wondering if it still matters at this point in time, the mask has been there for a long time and the package will probably be removed at some point; we're getting closer to removing them, as you can see in bug #483018. If you want, feel free to respond to java@gento.org as this is a security bug. > I use an application which needs dev-java/sun-jce-bin. Will that work with > say ibm java? Or will there be something working with ibm-jre-bin > ibm-jdk-bin? That depends on an application per application basis, guess you will need to try if the application doesn't list whether they are support. At best, we do correct the dependencies if we are told a certain VM doesn't work and we can confirm that; but, we can't completely cover every VM for every package given our time and resources. Thank you for your understanding. (In reply to Tom Wijsman (TomWij) from comment #10) > (In reply to Martin Mokrejš from comment #9) > > For users not much familiar with java the message referring to this bug > > number from package.mask file should give a *hint* what other package is > > believed to be a good replacement. > > Unmerging them will give a replacement; we can't judge what is good for you, > yet there is a default in place because it is listed first (that is > oracle-*). We cannot judge what would be a good replacement; so, I'm not > sure if we should do that. But this is exactly the reason why you should propose what are teh alternatives. Pokind through /usr/portage/dev-java/ is silly. > > From what I recall only one other user has shortly wondered about this in > #gentoo; so, maybe there is a need to change it. But I'm not sure to what, > suggesting people not to use something is safer than suggesting people to > move to something; after all, Gentoo is about choice. No, you should have a *whatever* automatic replacement for the functionality. That does not matter based on what criteria you came to the replacement package. That can be be always discussed eventually, but my point is that *every* user forced to unmerge dev-java/sun-{jdk,jre-bin} will have to poke through /usr/portage/dev-java/ and do: 1. Hey, what dirname look like a full java implementation. 2. Which of those evetually guessed correctly will be compatible with the sun-... java. 3. Try to emerge the new stuff. 4. Is there anything similar to "revdep-rebuild -i" which would tell the user: a) Hey, your system is left with orphaned dev-java/sun-jce-bin which cannot anymore. Install similar package X for you IBM java or Y for Oracle java. b) Or it could say. Sorry, there is no alternative for sun-jce-bin and sun-jce-bin won't use IBM/Oracle java. 5. user is left to try to install something and try out, one by one. So, what can you recommend me. The application for access to my bank account needs some Bouncycastle library from sun-jce-bin. What should I do except copying /usr/portage/dev-java/sun-jce-bin/ and /usr/portage/dev-java/sun-jre-bin to /usr/local/portage/dev-java/? I don't agree whatever "security" breach makes the package unusable. I even connect to my bank via DES or 3DES, my private uses much stronger cipher and even if I would regerate my key using low encryption (a paid process) I wouldn't like to connect over RC4-based SSL using whatever other fancy java VM (IBM, or is there any other left?). The bank maybe won't allow me to connect via weakly encypted channel and won't accept a weak certificate either. Don't know, I am sure I won't go that way ever. ;) Now, looking at the initial comment #1 I have doubts which of those seemingly many issues apply to me. I am starting the application locally on my system (it runs under my user privs immediately). That is already risky enough but java-webstart issues do not apply to me. If you drop the package it does not bring me any extra security I believe. Not only, it will either force me to use the app from vmware-based MS Win* OS, or install another Linux distro. Dropping packaging just because it seems fancy to do is not justifiable for me. Any software has some bugs and security bugs. I would better say work on a sandbox environment and teach users how to use the "insecure" java VM from within the sandbox. That is much more constructive. You can even add that to the package.mask file as a hint pointing to some HowTo doc. Same was the previous section on which other java VM would you recommend. You should recommend some if you want to drop this one. > > So, the question would be, how do we present the choices in a sane way? I > have no idea of a clean short command that would list them, preferably > without any extra tools; so, feel free to suggest one or otherwise I might > look into it. I'm thinking some short python call might list what satisfies > a virtual; so, I guess we could look that way. Move all VM ebuilds out of dev-java/ to some other "directory". Then it would be easier to see what are the other alternatives. Or yes, write the application which could list what other java VM's exist. Or in the end, as i wrote initially, a simple plaintext list of your suggestion would definitely work as well. ;-) > > Although I am wondering if it still matters at this point in time, the mask > has been there for a long time and the package will probably be removed at > some point; we're getting closer to removing them, as you can see in bug > #483018. I just don't believe you will drop it. ;) > > If you want, feel free to respond to java@gento.org as this is a security > bug. > > > I use an application which needs dev-java/sun-jce-bin. Will that work with > > say ibm java? Or will there be something working with ibm-jre-bin > > ibm-jdk-bin? > > That depends on an application per application basis, guess you will need to > try if the application doesn't list whether they are support. At best, we do > correct the dependencies if we are told a certain VM doesn't work and we can > confirm that; but, we can't completely cover every VM for every package > given our time and resources. Thank you for your understanding. I have not enough knowledge of java and thus do not know if an application will use sun-jce-bin with the BouncyCastle lib through other java VM. The only think I can do is to install some java VM or other package which you can recommend me and test. However, I fear you will immediately say that "sun-jce-bin" says it is only for "Sun" java so obviously won't be used from other VMs. So, by proper/helpful message in package.mask you could save us a lot of time if we skip blindly trying several VM and Googling around for crypto addons for each and we can migrate to MS Win more quickly. Requiring user action is really something what should be minimized on Linux, and definitely you should not push all users to consider "What are the other alternatives for me if I want to stay with Linux?". Please, provide them helpful guidance and some out-of-box solution, working for the most anticipated scenarios. Alternatives aren't important here. If people want to use the same functionality as sun java, they should upgrade to oracle java. oracle-jdk-bin and oracle-jre-bin are the follow-ons to the sun packages. Same source, both are distributed by oracle ever since they bought sun out a few years back, and when oracle released 1.7 we called that oracle java instead of sun java. There is no need to walk people through alternatives--this is no more than a change in package name. If sun worked before, oracle will be fine. (In reply to Chris Reffett from comment #12) > Alternatives aren't important here. If people want to use the same > functionality as sun java, they should upgrade to oracle java. > oracle-jdk-bin and oracle-jre-bin are the follow-ons to the sun packages. > Same source, both are distributed by oracle ever since they bought sun out a > few years back, and when oracle released 1.7 we called that oracle java > instead of sun java. There is no need to walk people through > alternatives--this is no more than a change in package name. If sun worked > before, oracle will be fine. So why isn't there an oracle-jce-bin? Because we aren't packaging it, it seems. The policy files exist upstream. File a bug to the java team to ask them to package it. (In reply to Martin Mokrejš from comment #11) > But this is exactly the reason why you should propose what are teh > alternatives. Pokind through /usr/portage/dev-java/ is silly. It indeed is, but there's no saner alternative requiring no more tools; eg. `eix --stable dev-java/*jdk*` doesn't appropriately match the actual JDK's, telling people to look into the virtual doesn't look neat either. > No, you should have a *whatever* automatic replacement for the functionality. This is not how security bugs are dealt with; feel free to discuss that with the security team through some other means to contact them, but that is outside the scope of this bug. Masks are manually dealt with by the users, GLSA's cover the instructions; removing the package that is masked has an automatic replacement. The remainder of your comment does therefore not apply due to the GLSA and automatic replacement upon unmasking. If this is is something missing from the GLSA; then yes, this bug might be the right place to address that matter. > The application for access to my bank account > needs some Bouncycastle library from sun-jce-bin. What should I do except > copying /usr/portage/dev-java/sun-jce-bin/ and > /usr/portage/dev-java/sun-jre-bin to /usr/local/portage/dev-java/? The mask merely is a suggestion, it does not force you to remove it; it is the removal of the package and mask that actually put on a force, and as you see, we're not yet at that point and that will come with its own documentation. Without more specifics on which library and which class in that library I cannot give you more advice; for all I can tell you based on that overview, we have bouncycastle packages dev-java/bc* but I can't tell more without details. > I don't agree whatever "security" breach makes the package unusable. > [...] > If you drop the package it does not bring me any extra security I believe. > [...] > Not only, it will either > force me to use the app from vmware-based MS Win* OS, or install another > Linux distro. > [...] > Dropping packaging just because it seems fancy to do is not > justifiable for me. Please note that we haven't forced or dropped anything here. Since the mask and GLSA are merely a message, the removal is your decision; Gentoo is about choice, and we delay the actual removal of the package for as long as we can as long as it can be reasonably maintained using our resources and time. The moment it becomes our decision is when we decide whether or not to maintain it anymore; and when that is, depends on more than just security. We are actually keeping this around much longer for users like you; as we are aware people would have problem with its removal, therefore this mask. > I would better say work on a sandbox environment and teach users how to use > the "insecure" java VM from within the sandbox. We have the hardened project for that, users can opt to use that or not; since not all users run hardened, we have to account for both parties. > You can even add that to the package.mask file as a hint pointing to some > HowTo doc. Same was the previous section on which other java VM would you > recommend. You should recommend some if you want to drop this one. That would imply we need to add that to every mask message; while you might be able to suggest that to the Portage developers, please note that users make the hardened choice up front so there is no gain for a specific mask message to reiterate that on its own. > > So, the question would be, how do we present the choices in a sane way? I > > have no idea of a clean short command that would list them, preferably > > without any extra tools; so, feel free to suggest one or otherwise I might > > look into it. I'm thinking some short python call might list what satisfies > > a virtual; so, I guess we could look that way. > > Move all VM ebuilds out of dev-java/ to some other "directory". JDK's are Java development; also even if I see that as a possibility, the policy for categories would reject the low number of JDK's to move to their own category. While the dev-java category is big though; for it to split, some broad categories are going to have to be figured out and up to this point nobody has been able to. > Then it > would be easier to see what are the other alternatives. Or yes, write the > application which could list what other java VM's exist. Or in the end, as i > wrote initially, a simple plaintext list of your suggestion would definitely > work as well. ;-) There is no such list as far as I know; so, I'd rather see a command here which we can repeat for future masks, instead of a list that doesn't cover reality. As I stated earlier; we are willing to improve mask reasons, but given the wide amount of people that receive them it's done in a careful and repeatable way. Can we please keep suggestions like these outside of a security bug? There are 80 people CC-ed; whereas the suggestion only matters to java@gentoo.org, so we would appreciate it if you continued through mail. Thank you in advance. > I just don't believe you will drop it. ;) In the same way we have dropped JDK 1-5; we delay that, for as long as we can. Thank you for your understanding, we aim to do things in the user's favor. Resources: - `man portage | grep 'quickly mask' -C4` - http://www.gentoo.org/security/en/ - http://www.gentoo.org/doc/en/security/security-handbook.xml - https://wiki.gentoo.org/wiki/Project:Hardened This issue was resolved and addressed in GLSA 201401-30 at http://security.gentoo.org/glsa/glsa-201401-30.xml by GLSA coordinator Sean Amoss (ackle). |
From ${URL} : Description Multiple vulnerabilities have been reported in Oracle Java, which can be exploited by malicious, local users to disclose certain sensitive information, manipulate certain data, and gain escalated privileges and by malicious people to conduct spoofing attacks, disclose certain sensitive information, manipulate certain data, cause a DoS (Denial of Service), and compromise a vulnerable system. 1) An unspecified error in the 2D component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 2) An unspecified error in the 2D component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 3) An unspecified error in the 2D component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 4) An unspecified error in the 2D component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 5) An unspecified error in the 2D component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 6) An unspecified error in the 2D component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 7) An unspecified error in the 2D component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 8) An unspecified error in the 2D component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 9) An unspecified error in the AWT component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 10) An unspecified error in the Deployment component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 11) An unspecified error in the Deployment component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 12) An unspecified error in the AWT component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 13) An unspecified error in the Deployment component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 14) An unspecified error in the Serviceability component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 15) An unspecified error in the Hotspot component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to cause a DoS. 16) An unspecified error in the Sound component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 17) An unspecified error in the Deployment component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to potentially execute arbitrary code. 18) An unspecified error in the Libraries component of the client and server deployment can be exploited to potentially execute arbitrary code. 19) An unspecified error in the Install component of the client installer can be exploited by local user to gain escalated privileges. 20) An unspecified error in the Libraries component of the client and server deployment can be exploited to disclose certain data and cause a DoS. 21) An unspecified error in the JDBC component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to disclose certain data and manipulate certain data. 22) An unspecified error in the Libraries component of the client deployment can be exploited to disclose certain data and manipulate certain data. 23) An unspecified error in the AWT component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to cause a DoS. 24) An unspecified error in the CORBA component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to disclose certain data. 25) An unspecified error in the Deployment component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to disclose certain data. 26) An unspecified error in the Deployment component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to manipulate certain data. 27) An unspecified error in the Deployment component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to manipulate certain data. 28) An unspecified error in the JMX component of the client and server deployment can be exploited via to manipulate certain data. 29) An unspecified error in the JMX component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to manipulate certain data. 30) An unspecified error in the Libraries component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to disclose certain data. 31) An unspecified error in the Libraries component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to disclose certain data. 32) An unspecified error in the Libraries component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to disclose certain data. 33) An unspecified error in the Networking component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to disclose certain data. 34) An unspecified error in the Serialization component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to cause a DoS. 35) An unspecified error in the Serialization component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to disclose certain data. 36) An unspecified error in the Serviceability component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to disclose certain data. 37) An unspecified error in the Libraries component of the client deployment can be exploited via untrusted Java Web Start applications and untrusted Java applets to disclose certain data. 38) Certain unspecified input passed via the URL to documentation generated with the Javadoc tool is not properly verified before being used to display content in frames. This can be exploited to display arbitrary content e.g. when a user clicks a specially crafted link to the affected script hosted on a web server. 39) An unspecified error in the Networking component of the client and server deployment can be exploited to gain escalated privileges. 40) An unspecified error in the 2D component of the client deployment can be exploited by a local user to disclose certain data and manipulate certain data. The vulnerabilities are reported in the following products: * JDK and JRE 7 Update 21 and prior * JDK and JRE 6 Update 45 and prior * JDK and JRE 5 Update 45 and prior Solution Apply updates. Further details available to Secunia VIM customers Provided and/or discovered by It is currently unclear who reported the vulnerabilities as the Oracle Java SE Critical Patch Update for June 2013 only provides a bundled list of credits. This section will be updated when/if the original reporter provides more information. Original Advisory Oracle: http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html http://www.oracle.com/technetwork/topics/security/javacpujun2013verbose-1899853.html @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.