We discused the same (for an older Version) here: https://issues.apache.org/jira/browse/IO-461?jql=text%20~%20%22veracode%22
Basically this is wrapper around a dangerous API, you might not use it in your code. If you do, you need to review your code. Note that the topic was quite popular with the Shellshock hype, but there are more (lingering) problems with spawning executables, constructing environment variables and command lines. Unfortunatelly (or not?) the lib does not shield you from those. Gruss Bernd Am Wed, 10 Feb 2016 11:14:09 -0200 schrieb Edson Richter <edsonrich...@hotmail.com>: > > > ---- Mark Thomas escreveu ---- > > > On 10/02/2016 12:00, Parag Joshi wrote: > > > Hi, > > > > > > > > > > > > I am using Apache Commons IO v2.4 (commons-io-2.4.jar) in one of > > > my projects. My organization uses Veracode to scan the deliveries > > > of my project. Veracode scans the projects for vulnerability > > > issues and flags the flaws if the code and/or third-party > > > libraries used in the project are vulnerable for some external > > > attacks. > > > > > > > > > During the recent scan the Veracode system flagged an issue in > > > commons-io-2.4.jar. > > > > > > > > > Below are the details: > > > > > > > > > *CWE ID:* 78 > > > > > > http://cwe.mitre.org/data/definitions/78.html > > > > > > *Name:* Improper Neutralization of Special Elements used in an OS > > > Command ('OS Command Injection') > > > > > > *Module:* commons-io-2.4.jar > > > > > > *Source:* FileSystemUtils.java: *Line#* 535 > > > > > > *Attack Vector: *java.lang.Runtime.exec > > > > > > *Description:* This call to java.lang.Runtime.exec() contains a > > > command injection flaw. The argument to the function is > > > constructed using user-supplied input. If an attacker is allowed > > > to specify all or part of the command, it may be possible to > > > execute commands on the server with the privileges of the > > > executing process. The level of exposure depends on the > > > effectiveness of input validation routines, if any. The first > > > argument to exec() contains tainted data from the variable > > > cmdAttribs. The tainted data originated from earlier calls to > > > java.lang.string.!operator_javanewinit, > > > java.io.file.!operator_javanewinit, > > > org.apache.commons.io.filesystemutils.freespacekb, > > > org.apache.commons.io.filesystemutils.freespacekb, > > > org.apache.commons.io.filenameutils.normalize, > > > org.apache.commons.io.filenameutils.getprefixlength, and > > > org.apache.commons.io.filesystemutils.freespace. > > > > > > *Remediation:* Validate all user-supplied input to ensure that it > > > conforms to the expected format, using centralized data > > > validation routines when possible. When using black lists, be > > > sure that the sanitizing routine performs a sufficient number of > > > iterations to remove all instances of disallowed characters. Most > > > APIs that execute system commands also have a "safe" version of > > > the method that takes an array of strings as input rather than a > > > single string, which protects against some forms of command > > > injection. > > > > > > Now, my organization needs an assessment report for the above > > > issue from the author of the third-party library which in this > > > case it is Apache. Can you please provide me the assessment > > > report for above issue? > > > > With my ASF security team member hat on: > > No. > > > > > Is this a known issue? > > > > That question is based on the assumption that an issue exists. > > > > > And is it safe to use commons-io-2.4.jar keeping in mind the > > > above issue? > > > > No idea. It is your code using the library so they only person who > > can say how the library is used is you. > > > > Is if possible to use this library in such a way as to expose you > > to a remote code execution vulnerability? Sure. It is also possible > > to use the library safely. How you use it is up to you and you have > > to take responsibility for that. > > > > Mark > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > > For additional commands, e-mail: user-h...@commons.apache.org > > Also, considering Apache Commons is an Open Source software, you are > welcome to download sources, develop a "patch" and contribute back, > making world a safer place for all of us. > > Regards, > > Edson Richter --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
