You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Parag Joshi <pa...@gmail.com> on 2016/02/10 13:00:53 UTC
[IO] Query on Veracode issue
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? Is this a
known issue? And is it safe to use commons-io-2.4.jar keeping in mind the
above issue?
Thanks in advanced,
Parag Joshi
Re: [IO] Query on Veracode issue
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
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 <ed...@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [IO] Query on Veracode issue
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Feb 10, 2016 at 5:14 AM, Edson Richter <ed...@hotmail.com>
wrote:
>
>
> ---- 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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@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.
>
+1!
Gary
>
> Regards,
>
> Edson Richter
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [IO] Query on Veracode issue
Posted by Edson Richter <ed...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@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
Re: [IO] Query on Veracode issue
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org