Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: bsh (BeanShell) security vulnerability (CVE-2016-2510)

79 views
Skip to first unread message

Emmanuel Bourg

unread,
Feb 19, 2016, 8:40:03 AM2/19/16
to
Hi Stian,

Thank you for the notice. Technically this isn't a vulnerability in bsh
though, the issue is any application deserializing untrusted data
without sanitizing it and having bsh on the classpath. I'm not aware of
such applications in Debian, but if there is one it should be fixed in
priority instead of playing whac-a-mole with the serialization code in
the 800+ Java libraries in Debian.

Regarding your fork on GitHub, did you get the authorization from the
original author (Patrick Niemeyer) to change the license from LGPL-2 to
Apache-2.0? Also why was the Maven groupId changed from org.beanshell to
org.apache-extras.beanshell?

Emmanuel Bourg

Stian Soiland-Reyes

unread,
Feb 19, 2016, 11:30:07 AM2/19/16
to
Hi, thanks. I agree that this is a general Java issue in any
application using serialization - the vulnerability attack vector
would just move to less common libraries (we point this out in the
release notes).
Also I must admit for me it was a bit confuising at first to learn
about how a scripting language could be used to run arbitrary code -
well that's the point! :-) However the issue could arrise just by
having
bsh.jar on the classpath and doing any other kind of deserialization
from files or the network.


Patrick Niemeyer (CC) did the license change as part of the code
donation to ASF:
https://github.com/beanshell/beanshell/commit/8bac4930744cc62134125263b3e61ef04e296c80

Pat is also part of the https://github.com/beanshell team.

I've added a brief History section to
https://github.com/beanshell/beanshell#history - perhaps Pat want to
review that :)



We changed the groupId for 2.0b5 as it was unclear at the time what
was the relationship with beanshell.org, and also beanshell.org also
had an existing 2.0b5 release under LGPL.

Since Google Code shut down http://apache-extras.org/ as a domain name
has become a bit meaningless, so now org.apache-extras.beanshell is
not a good groupId.

We could probably change the groupId back to org.beanshell and as a
GitHub project take over management of the http://beanshell.org/
website - but there's a bit of legacy to maintain there (e.g. older
releases and Beanshell 1) - so that's up to Pat to decide - perhaps
just a banner pointing to the GitHub page would be enough?

I've added https://github.com/beanshell/beanshell/issues/17 to discuss this.

There is also the fork https://github.com/pejobo/beanshell2 - but
pejobo has also joined https://github.com/beanshell so hopefully his
patches there would move across. (They have to be recontributed by the
original authors as beanshell2 was LGPL)
> --
> To unsubscribe, send mail to 700610-un...@bugs.debian.org.



--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718

Thomas Uhle

unread,
Feb 22, 2022, 6:00:03 PM2/22/22
to
Dear maintainers,

there was published a new release of BeanShell 14 months ago. You can find
the sources of version 2.1.0 on GitHub at

https://github.com/beanshell/beanshell/releases/tag/2.1.0

The new version has not been published on Maven though (where versions
from 2.0b4 to 2.0b6 are still the newest releases), but this is explained
on GitHub at https://github.com/beanshell/beanshell/issues/603 .
Anyway, version 2.1.0 is an official release linked from
https://www.beanshell.org/download.html and there is also stated that
version 2.0b4 is now merely a legacy release.

What do you think, wouldn't it be time for an update in Debian?

Best regards,

Thomas Uhle

Thorsten Glaser

unread,
Feb 22, 2022, 6:40:03 PM2/22/22
to
On Tue, 22 Feb 2022, Thomas Uhle wrote:

> What do you think, wouldn't it be time for an update in Debian?

The comment
> at https://github.com/beanshell/beanshell/issues/603 .
reads for me more like a “maybe remove it instead…”.

Honestly though, if it’s not available in Central, upstreams will
not use it and stick to old beta versions. If Debian has a newer
one, which may be incompatible, we’re inviting problems.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

Thomas Uhle

unread,
Feb 25, 2022, 4:40:03 PM2/25/22
to
On Wed, 23 Feb 2022, Thorsten Glaser wrote:

> On Tue, 22 Feb 2022, Thomas Uhle wrote:
>
> > What do you think, wouldn't it be time for an update in Debian?
>
> The comment
> > at https://github.com/beanshell/beanshell/issues/603 .
> reads for me more like a “maybe remove it instead…”.
>
> Honestly though, if it’s not available in Central, upstreams will
> not use it and stick to old beta versions. If Debian has a newer
> one, which may be incompatible, we’re inviting problems.

That might be true although the BeanShell developers claim in their
announcment of version 2.1.0 to be backward compatible with version 2.0b6,
and only suitable backports from the upcoming version 3.0 of BeanShell
have made it into version 2.1.0. But even then Debian could move on to
version 2.0b6 at least. It is the latest version of BeanShell on Maven
Central.

Perhaps we might have a better picture after a look at other Linux
distributions. Arch, Fedora and Mageia for instance already have version
2.1.0 onboard whereas Gentoo, OpenMandriva, openSUSE and Red Hat stay with
version 2.0b6 (... to name just a few). So it is quite mixed. But I
haven't seen any Linux distribution so far (apart from those derived from
Debian like Linux Mint, Ubuntu, etc.) that still have version 2.0b4.
It seems that both decisions (either to update to version 2.1.0 or to
version 2.0b6) are reasonable.

Best regards,

Thomas Uhle
0 new messages