Vulnerability in beanutils: CVE-2014-0114
Brought to you by:
aruckerjones,
sconway
Menu
▾
▴
#65 Vulnerability in beanutils: CVE-2014-0114
commons-beanutils Jar has known vulnerability:
https://nvd.nist.gov/vuln/detail/CVE-2014-0114
Can't use this opencsv because enterprise policies forbid using libraries with known vulnerabilities.
Update your version of opencsv to any version 3.9 or later (current released version is 4.5) .
According to the link you sent the vulnerability is in any version <= 1.9.2 and we upgraded to version 1.9.3 in the 3.9 release.
Double checking on a different site shows that 1.9.3 does not have the issue.
https://www.sourceclear.com/vulnerability-database/libraries/Apache-Commons-BeanUtils/JAVA/MAVEN/lid-219
Scott :)
Hi Scott. I see what you're saying but the jar is still flagged because of resolution depends on a configuration that " However, this fix is not enabled by default". I wouldn't be setting any properties on a dependency to a dependency and finally the enterprise scanner just says no so that's that. Anyway, just a follow up for your information. Thanks again.
Hello Karl - Sorry I could not reply right away.
First off my sympathies for having such restrictive enterprise policies. Having to maintain PCI compliance I really do feel your pain. Doubly so because as strict as I thought the company I worked for was they at least have not forced us to upgrade because all the automated scans we do on each build (and actual manual intrusion attempts on occasion) have all passed showing we have not exposed any of the vulnerable code. So you have really provided proof to me that the grass is not always greener on the other side.
That said if your company is forbidding the use of libraries due to vulnerabilities does your company have a list of acceptable alternatives for commons-beanutils? That would give a good starting point for anyone who wanted to pick up the issue.
Hi Scott. Yea, they don't go that far even though the motto is "let's go all the way" :). I'd be happy to take a look and see what I can figure out but I'd need to know what you consider the minimum JVM to be . 1.6, 1.7, 1.8? Obviously the later the better. The bean-utils seems to be pretty old so there is probably a newer equvilent or something as part of java now.
Sadly we are still using Java 7. Way back when we pushed out opencsv 3.0 we moved from Java 5 to Java 7 (which had just reached end of life) and there was an horrific backlash because a number of users were still using Java 6. After that I came up with a Apache Commons rule - I kept compiling opencsv in java 7 because I did not have a java 5 compiler anymore but I applied a patch submitted by user to where it could be compiled in java 6 and kept it that way until apache commons-lang required java 7 before I would use java 7 syntax (and at that point no one screamed). So I am going the same route with future versions of Java just to make sure I am not leaving a bunch of developers behind. Otherwise, despite what other people think, I would be seriously considering Java 11 since Java 8 is past end-of-life.
That said I am wondering if apache stopped development on BeanUtils because of the additions of the reflect package in apache commons-lang (https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/reflect/package-summary.html).
I googled around and really could not find anything else remotely like beanutils that did not involve automatically converting classes to JSON or XML.
Scott :)
Java 7 should be getting replaced by Java 8 soon enough though I don't see everyone dropping 8 in favor of 11 anytime soon just because of momentum. The improvements for containers should help. I dl'd the source and got it to compile on my windows machine and sent a merge request with the changes required. Just test cases and pom stuff. I added a helper plugin for eclipse. I'd be interested in looking further at the bean utils stuff but I need to make sure I can contribute in general first. I saw a fair number of warnings in the current code and it might make sense to look at those a little bit first to get a handle on things.
If all you want to do is fix code warnings I am tickled just as well - I
accept any and all help... With a long list of cavets but they mostly
break down to "Don't break anything for the current users" and "Don't
"fix" the tests."
I did merge in your last push. Originally I was reluctant but I saw the
areas you removed the versions were for items that were in dependency
management. I am still iffy about the assertSame because I have yet to
see a business case that states that the exact object that gets passed into
a method should be the object that does blah - or put another way to me
assertSame is but one defensive copy away from failing a test that it
should not. But since they are Strings you are asserting on it should be
okay.
If there are any other changes you wish to make feel free and I will review
them and merge them or contact you with any issues I feel there are.
Currently I am planning on a 4.6 release sometime after Easter (may do it
sooner but currently life is too hectic). But don't feel rushed because if
there is something you feel needs to go out I can push another release when
I have free time as it takes around a 30-60 minutes from start to finish
depending on the distractions around the house <bg>.</bg>
Scott :)
On Fri, Mar 29, 2019 at 5:52 PM Karl Nicholas karlnicholas@users.sourceforge.net wrote:
--
Scott Conway
scott.conway@gmail.com
http://www.conwayfamily.name
Related
Support Requests:
#65Hi Scott,
I've looked a little closer at the source and see there are two major areas of opencsv. The first is the core CSV reader and the second is the bean binding area. The most obvious and easy solution for this is to split the project into two separate jars, one for the core stuff and one for the bean binding.
The bean binding has most (or all) of the external dependencies and also has the warnings that I previously mentioned. Most of the warnings seem to have to do with improper use of Java generics and others seem to be related to deprecated code. I don't think deprecated is an issue except that some of the internal code still seems to use the deprecated methods so that is another case of improper use of Java features. In the brief time I looked at the bean areaI also noticed cases of hidden parameters or the like. For example passing a null into a constructor to make it act a certain way, or testing if a class is an instanceof a String to change behavior. Oh, I also noticed that one warning was a case of a private no-arg constructor that was never called but made private so it couldn't be called. In Java, however, if there are other constuctors then you don't need to hide a no-arg constructor because it wont exsist anyway. The author(s) of the bean area seemed to have a somewhat underdeveloped understanding of Java besides using several external dependencies, something that should be avoided in the case of utility libraries such as opencsv.
So besides the core and bean areas being a useful segregation for the purpose of addressing this particular issue it is also useful for segregating for the purpose of allowing independent work on the two areas. A useful refactoring of the bean area seems like, at this point, a fairly substantial effort and would probably require changes in methods and documentation to address the hidden parameter idiosyncrasies.
I tried deleting the bean area of the source and the remaining core didn't have any compilation problems. There were some test case interdependencies but they seemed easy to sort out. If you are willing to accept such a merge request I'm happy to do it.
Thanks,
Karl.
Considering moving to https://jodd.org/beanutil/ for opencsv 5.0, but I haven't researched enough to make that definitive.
Jodd BeanUtil looks like a dead end. It currently doesn't support locales, which we do. Not sure how much more research I'm going to do before I abandon this idea. I did open a ticket with Jodd to request locale support.
I received a prompt reply to my ticket yesterday requesting locale-specific conversions in Jodd BeanUtil. The developer agrees that it makes sense and said he would prioritize the feature.
Sweet!
On Tue, May 14, 2019 at 10:28 PM Andrew Rucker Jones aruckerjones@users.sourceforge.net wrote:
--
Scott Conway
scott.conway@gmail.com
http://www.conwayfamily.name
Related
Support Requests:
#65FWIW, OpenCSV only uses
commons-beanutils'Converterclasses, which don't use the vulnerablePropertyUtilsBeanand related classes. Hence, I'd consider OpenCSV not affected by this CVE. What do you think?IMO it might not even be necessary to replace
commons-beanutilsas long as only itsConverterclasses are used.Thanks for verifying that. I agree since we do not use the offending methods in commons-beanutils I agree it is not effected by that CVE. If your compaines vulnerablity scanner allows you to file exceptions I would do that.
Just to wrap it up, even though I haven't tried to get an exception I don't think it would work or be worth the effort. There would be too many questions including whether or not an alternative is available and which specific version is needed and how long before the vulnerability is expected to be fixed. I like opencsv but stick by my original recommendation that you modularize it and do some updating of the code. Thanks.
Just for recordkeeping purposes: I still have received no further response from the Jodd developers. I doubt we will make the switch in 5.0, and since it could possibly impact backward compatibility, it may not happen in the entire 5.x branch.
On the upside, 5.0 will update its dependency to the recently released BeanUtils 1.9.4, which according to the release notes, solves the CVE in question.
opencsv 5.0 has been released.