Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 161835 - dev-java/blackdown-(jdk|jre): multiple vuln. with buffer overflows (?)
Summary: dev-java/blackdown-(jdk|jre): multiple vuln. with buffer overflows (?)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: http://sunsolve.sun.com/search/docume...
Whiteboard: B?2? [glsa]
Keywords:
Depends on: 179275
Blocks:
  Show dependency tree
 
Reported: 2007-01-12 22:43 UTC by Raphael Marichez (Falco) (RETIRED)
Modified: 2020-02-13 08:18 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2007-01-13 01:45:43 UTC
Yeah, but latest blackdown is only 1.4.2.03, based on Sun's 1.4.2.10, so we can't just bump it (upstream looks pretty dead). Though the bugs look like they are only about applets (which means the nsplugin in browsers) so we could just stop installing the plugin. But it's the only JDK/JRE with 64bit browser plugin for amd64. Users would then have to use 32bit browser with emul-linux-x86-java to have java browser plugin. Unless that 64bit->32bit plugin wrapper that's used for flash works with java too.
Comment 2 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-03-25 10:31:44 UTC
Any news on this one?
Comment 3 Petteri Räty (RETIRED) gentoo-dev 2007-03-25 10:43:11 UTC
(In reply to comment #2)
> Any news on this one?
> 

I don't think it's a big problem to remove nsplugin support from blackdown-jdk as from what I hear it's prone to crashes but let's get the opinion from the amd64 arch team. The change would also need to be documented to the Java guide at least. Maybe we could have a virtual/java-browser-plugin that would pull in something that provides the plugin.
Comment 4 Petteri Räty (RETIRED) gentoo-dev 2007-04-08 18:52:55 UTC
Ok experiences from gentoo-java mailing lists show that we should remove the nsplugin support from blackdown-java. Doc monkeys: Please change http://www.gentoo.org/doc/en/java.xml to update it so that we are disabling the 64 bit plugin which leaves 32 bit plugin as the only option. I can check the diff if you are unsure about the changes.
Comment 5 nm (RETIRED) gentoo-dev 2007-04-08 19:53:37 UTC
(In reply to comment #4)
> Ok experiences from gentoo-java mailing lists show that we should remove the
> nsplugin support from blackdown-java. Doc monkeys: Please change
> http://www.gentoo.org/doc/en/java.xml to update it so that we are disabling the
> 64 bit plugin which leaves 32 bit plugin as the only option. I can check the
> diff if you are unsure about the changes.
> 

Betelgeuse said he'd ask on the gentoo-user ML about this, and I setup a poll[1] on the forums, so let's get some more widespread user feedback on this before the thing is removed entirely. :)

[1] http://forums.gentoo.org/viewtopic-t-552110.html
Comment 6 Steve Dibb (RETIRED) gentoo-dev 2007-04-26 19:27:38 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Ok experiences from gentoo-java mailing lists show that we should remove the
> > nsplugin support from blackdown-java. Doc monkeys: Please change
> > http://www.gentoo.org/doc/en/java.xml to update it so that we are disabling the
> > 64 bit plugin which leaves 32 bit plugin as the only option. I can check the
> > diff if you are unsure about the changes.
> > 
> 
> Betelgeuse said he'd ask on the gentoo-user ML about this, and I setup a
> poll[1] on the forums, so let's get some more widespread user feedback on this
> before the thing is removed entirely. :)
> 
> [1] http://forums.gentoo.org/viewtopic-t-552110.html
> 

Betelgeuse, any comments?  My vote is for p.use.masking the flag for our arch.
Comment 7 Steve Dibb (RETIRED) gentoo-dev 2007-04-27 02:26:41 UTC
use flag masked on the amd64 arch
Comment 8 nm (RETIRED) gentoo-dev 2007-04-27 02:32:11 UTC
(In reply to comment #7)
> use flag masked on the amd64 arch

So, uh, does this mean I should go ahead and change the java documentation?
Comment 9 Jon Severinsson 2007-04-27 07:16:08 UTC
I'd like to comment on the absurdness of the current situation:

The only arch that needs blackdown nsplugin is amd64
The only arch that disables blackdown nsplugin is amd64

In my thinking you should globally disable nsplugin for blackdown, just as you do for sun-j{re,dk}, but then unmask it for amd64 only, as for all other arches you'd better use sun-j{re,dk} for nsplugin, while for amd64 you don't have that option.
Comment 10 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-04-27 08:53:27 UTC
Problem is blackdown's plugin is very unstable on amd64. It crashes the browser allot. Which is most of the reason for masking and making it not available. Really the only option ATM for a Java plugin on amd64 is to use a 32bit bin browser, with a emul-linux-x86-java package.
Comment 11 Jon Severinsson 2007-04-27 09:11:12 UTC
Crashing sometimes is better than never working, and I'd very much like not having to install all the 32bit emul libraries just so that I have to switch browser every time I need Java.
Comment 12 Bo Ørsted Andresen (RETIRED) gentoo-dev 2007-04-27 09:23:50 UTC
(In reply to comment #11)
> Crashing sometimes is better than never working, and I'd very much like not
> having to install all the 32bit emul libraries just so that I have to switch
> browser every time I need Java.

Any user who wants a crashing plugin can just unmask the use flag themselves in /etc/portage/profile/.
Comment 13 Jon Severinsson 2007-04-27 09:31:37 UTC
Thanks for the pointer, I'd already tried to put a package.use.mask containing "dev-java/blackdown-jdk -nsplugin" in /etc/portage (next to package.use and package.mask), but that didn't work, so I thought I'd have to resort to sed-ing the portage tree after every sync, but after moving package.use.mask to /etc/portage/profile/ it started working. Now, just please don't remove the actual nsplugin logic from the ebuild, even if it gets masked on all arches.
Comment 14 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2007-04-27 10:06:26 UTC
I agree that mask only on amd64 makes no sense.
1) we should mask it everywhere
2) (optionally? betelgeuse suggested this) unmask only for amd64 (x86 can use sun-jdk) AND only for the ~arch revision (which should then give ewarn that the plugin is vulnerable and unsupported)
3) update docs, based on the decision about 2) Worth noting is maybe that there's another alternative, using konqueror you don't need nsplugin, it uses java (your system/user vm) directly so it can be 64bit sun-jdk as well.
4) emul-linux-java-1.4 is currently blackdown, really should change it to sun-jdk even if there's fetch restriction
Comment 15 Petteri Räty (RETIRED) gentoo-dev 2007-04-27 11:26:51 UTC
(In reply to comment #7)
> use flag masked on the amd64 arch
> 

And why did you do that? The documentation was supposed to be done first.
Comment 16 Pacho Ramos gentoo-dev 2007-04-27 12:14:25 UTC
(In reply to comment #10)
> Problem is blackdown's plugin is very unstable on amd64. It crashes the browser
> allot. Which is most of the reason for masking and making it not available.
> Really the only option ATM for a Java plugin on amd64 is to use a 32bit bin
> browser, with a emul-linux-x86-java package.
> 

Or maybe, install net-www/nspluginwrapper-0.9.91.4 ;-) 
Comment 17 Pacho Ramos gentoo-dev 2007-04-27 12:20:24 UTC
(In reply to comment #14)
> 4) emul-linux-java-1.4 is currently blackdown, really should change it to
> sun-jdk even if there's fetch restriction
> 

emul-linux-x86-java-1.4* is really needed?

Currently, I only have emul-linux-x86-java-1.5.0.10 installed on my system :-/
Comment 18 Steve Dibb (RETIRED) gentoo-dev 2007-04-27 13:11:48 UTC
(In reply to comment #15)
> (In reply to comment #7)
> > use flag masked on the amd64 arch
> > 
> 
> And why did you do that? The documentation was supposed to be done first.
> 

sorry bout that, didn't catch that one.

Last time I talked to nightmorph, he was going to update it anyway.
Comment 19 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-04-27 13:56:06 UTC
(In reply to comment #11)
> Crashing sometimes is better than never working, and I'd very much like not
> having to install all the 32bit emul libraries just so that I have to switch
> browser every time I need Java.
> 

For me it was crashing most all times. Way more than not, IMHO pretty unusable. As for the 32bit emul Java. I guess you don't want Flash either since that requires a 32bit browser as well.

For quite some time I was a purist only running 64bit browsers, but after time, there was no point. Hardly any diff on performance and etc, and 64bit no java/flash vs 32bit with both. 32bit is likely the best way to go.



(In reply to comment #17)
>
> emul-linux-x86-java-1.4* is really needed?
> 
> Currently, I only have emul-linux-x86-java-1.5.0.10 installed on my system :-/

The only 1.4 emul one packaged is blackdown :( Which IMHO really should be Sun's. But a 1.5 plugin or greater should be just fine, should be able to view all 1.4 applets and etc.

I would go with 1.5 or 1.6
Comment 20 Petteri Räty (RETIRED) gentoo-dev 2007-04-27 15:45:43 UTC
(In reply to comment #14)
> I agree that mask only on amd64 makes no sense.
> 1) we should mask it everywhere

Masked everywhere. I didn't unmask it for ~arch because that has the potential for breakage if we forget to update the profiles with revision bumps. Let's just document using /etc/portage/profile/package.use.mask to unmask it.
Comment 21 nm (RETIRED) gentoo-dev 2007-04-29 02:39:18 UTC
(In reply to comment #18)

Documentation updated.

I did not, however, mention how to unmask the flag locally. The flag was masked for the obvious reasons you all know -- unresolved security vulnerabilities are serious issues, to say nothing of blackdown's total instability. We wouldn't document the usage of masked or removed packages because of their security/stability problems; it would be just as stupid to document unmasking the flag.
Comment 22 Petteri Räty (RETIRED) gentoo-dev 2007-04-29 10:21:29 UTC
(In reply to comment #21)
> (In reply to comment #18)
> 
> Documentation updated.
> 

All done here then. Unless the security team wants to write a GLSA for people to stop using blackdown nsplugin?
Comment 23 nm (RETIRED) gentoo-dev 2007-04-29 18:15:06 UTC
(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #18)
> > 
> > Documentation updated.
> > 
> 
> All done here then. Unless the security team wants to write a GLSA for people
> to stop using blackdown nsplugin?

I think that's a good idea. Go all the way and treat this as seriously as any other package that upstream hasn't fixed -- I'm even for removing the flag from the ebuild altogether until the issues are fixed. I think that this should be taken seriously, and well, when packages have unresolved security issues, they're removed from the tree. Why should the USE flag for blackdown be any different?

The "pure 64-bit environment argument for keeping the flag in the ebuild" doesn't apply, as konqueror can use a 64-bit java VM directly without the plugin flag.
Comment 24 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-04-30 09:37:42 UTC
Security please vote on a mask GLSA for this one.
Comment 25 Matt Drew (RETIRED) gentoo-dev 2007-05-01 11:27:26 UTC
/vote yes for maskglsa - if upstream is dead, there's no other option.
Comment 26 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-05-03 18:41:17 UTC
voting yes too.
Comment 27 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-05-04 22:36:28 UTC
OK but how will we handle such a GLSA. There is no "affected version", glsa-check will either always report a vulnerable package, or always an unaffected package.
Comment 28 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-05-04 22:47:11 UTC
BTW does any official source mention that only web applets are vulnerable? Are you sure standard Java applications (.class) are not vulnerable?
Comment 29 Petteri Räty (RETIRED) gentoo-dev 2007-05-04 22:49:38 UTC
(In reply to comment #28)
> BTW does any official source mention that only web applets are vulnerable? Are
> you sure standard Java applications (.class) are not vulnerable?
> 

"Security Vulnerabilities Related to Serialization in the Java Runtime Environment may Allow Untrusted Applets to Elevate Privileges"

Normal Java applications run without sandboxing so they can pretty much do what they want like applications written in C/C++.
Comment 30 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2007-05-04 22:51:16 UTC
Blackdown is "Based on Sun's 1.4.2-10 source code" which means any older vulnerability there's for sun 1.4.2.10 most probably applies here. Not sure if I recall any not related to applets.
Comment 31 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-05-06 22:25:46 UTC
would it be possible to rev-bump the ebuilds, without the nsplugin USEflag, in order to force our users to upgrade their system, and to make glsa-check warn as expected?
Comment 32 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-05-10 18:35:08 UTC
Ping java on comment #31.
Comment 33 Petteri Räty (RETIRED) gentoo-dev 2007-05-10 18:39:35 UTC
(In reply to comment #31)
> would it be possible to rev-bump the ebuilds, without the nsplugin USEflag, in
> order to force our users to upgrade their system, and to make glsa-check warn
> as expected?
> 

Well isn't a revision bump with the nsplugin use flag masked as it is ok?
Comment 34 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-05-14 21:04:54 UTC
(In reply to comment #33)
> (In reply to comment #31)
> > would it be possible to rev-bump the ebuilds, without the nsplugin USEflag, in
> > order to force our users to upgrade their system, and to make glsa-check warn
> > as expected?
> > 
> 
> Well isn't a revision bump with the nsplugin use flag masked as it is ok?
> 

(sorry for the late answer)

It will be OK, although i prefer not globally killing the nspluging useflag. Then we will be able to send a correct GLSAs with proper version numbers, and unsure that a normal "emerge world" will work around the vulnerability.
Comment 35 Petteri Räty (RETIRED) gentoo-dev 2007-05-14 21:16:23 UTC
(In reply to comment #34)
> > Well isn't a revision bump with the nsplugin use flag masked as it is ok?
> > 
> 
> (sorry for the late answer)
> 
> It will be OK, although i prefer not globally killing the nspluging useflag.

Makes no sense to me? Where am I suggesting to kill it?
Comment 36 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-05-17 13:14:29 UTC
the "nspluging" useflag would be masked for that package. It would affect all versions of the package. I would prefer a revision bump, without the "nsplugin" useflag, and without masking this useflag. Thus, the older versions will not be affected if someone wants to reemerge an old version. And glsa-check will continue to complain because of the vulnerability.

But it is late now, and if you disagree, feel free to revbump + mask.

Well, after all, as you prefer :)
Comment 37 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2007-05-20 21:53:12 UTC
(In reply to comment #36)
> the "nspluging" useflag would be masked for that package. It would affect all
> versions of the package. I would prefer a revision bump, without the "nsplugin"
> useflag, and without masking this useflag. Thus, the older versions will not be
> affected if someone wants to reemerge an old version. And glsa-check will
> continue to complain because of the vulnerability.

That would be hard to maintain, assuming we would want to leave some version with nsplugin around, as some people want to use it no matter what. With all revbump we would have to revbump both affected and unaffected and update glsa for the new revbumps.

> But it is late now, and if you disagree, feel free to revbump + mask.

Done
vulnerable:
< blackdown-jdk-1.4.2.03-r14
< blackdown-jre-1.4.2.03-r14

unaffected:
>= blackdown-jdk-1.4.2.03-r14
>= blackdown-jre-1.4.2.03-r14

Just note in the GLSA that in order to stay unaffected, one must not unmask the masked nsplugin flag. And I realized one needs portage >=2.1.1 for use.mask to work. Can you force that in the glsa? Our eclass already sets portage DEPEND to >=2.1 and in the tree there's 2.1.1-r2 the lowest matching this. So maybe glsa update will already pull this even if user has only 2.1 installed, not sure.

I think the best solution would be to extend glsa to allow built_with_use-like checks, I can imagine more situations where we use.mask some flag for security but want to keep it usable for those who don't care.
Comment 38 nm (RETIRED) gentoo-dev 2007-05-27 02:27:24 UTC
I notice that on the GLSA forums thread, the text of it reads: 

" Chris Evans has discovered multiple buffer overflows in the Sun JDK and the Sun JRE possibly related to various AWT and font layout functions. Tom Hawtin has discovered an unspecified vulnerability in the Sun JDK and the Sun JRE relating to unintended applet data access. He has also discovered multiple other unspecified vulnerabilities in the Sun JDK and the Sun JRE allowing unintended Java applet or application resource acquisition."

Notice the continual references to "Sun", despite the fact that this GLSA is for the Blackdown Java implementation. There's all the talk about Sun, yet at the end of the GLSA, it recommends that users switch *to* the Sun Java implementation to avoid the nsplugin issue. This is a point of confusion for users; it should be clarified.
Comment 39 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-05-30 19:44:02 UTC
GLSA 200705-20, thanks everybody

@caster: well it's possible to add "vulnerable portage<2.1.1" in the GLSA, but that would bring too much complication in regard of the benefit, imho.

@nightmorph: well mmm, yeah, but the vulnerabilities mentioned in the GLSA are always fixed at the time the GLSA is sent. (except if it's a "maskglsa", with masked package).
Comment 40 Michele Schiavo 2007-10-09 21:21:01 UTC
Why it still (-nsplugin) on amd64?