[jira] [Comment Edited] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712330#comment-16712330
]
Rasmita Mahapatra edited comment on FILEUPLOAD-279 at 12/7/18 4:58 AM:
---
Please confirm, which build I can use, 1.4-SNAPSHOT latest or better to fall
back to 1.3.3
Is CVE-2016-131 vulnerability is not present in
"commons-fileupload-1.4-20160119.063138-53.jar" SNAPSHOT build, then I we don't
need to upgrade the jar.
h1.
was (Author: rasmita):
Please confirm, which build I can use, 1.4-SNAPSHOT latest or better to fall
back to 1.3.3
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712330#comment-16712330
]
Rasmita Mahapatra commented on FILEUPLOAD-279:
--
Please confirm, which build I can use, 1.4-SNAPSHOT latest or better to fall
back to 1.3.3
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to read in the file
> from disk.
> That filename is always generated via getOutputStream.
> Serialized Object Modification
> The rules listed above do
[jira] [Created] (NUMBERS-80) Quaternion Updates for commons-geometry
Matt Juntunen created NUMBERS-80:
Summary: Quaternion Updates for commons-geometry
Key: NUMBERS-80
URL: https://issues.apache.org/jira/browse/NUMBERS-80
Project: Commons Numbers
Issue Type: Task
Reporter: Matt Juntunen
The {{Quaternion}} class should be updated in order to allow the
{{QuaternionRotation}} class from commons-geometry to extend it. The following
updates are required:
- Remove {{final}} class modifier.
- Make constructor protected.
In addition, it would be good to switch the names of the components from {{q0,
q1, q2, q3}} to {{w, x, y, z}}. The former assumes that the convention that the
scalar component is always listed first, which is not the case in some domains.
The latter convention is not ambiguous.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712168#comment-16712168
]
Otto Fowler commented on VFS-398:
-
[~garydgregory] Thanks for the feedback. I will apply your patch, and get to
work on that.
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-398:
-
Attachment: VFS-398-gg-00.patch
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712066#comment-16712066
]
Gary Gregory commented on VFS-398:
--
Hi [~ottobackwards]
I've taken your patch and updated it as [^VFS-398-gg-00.patch]
* Name changes
* Javadoc changes
What remains are the uses of the APIs you deprecated, namely:
* {{org.apache.commons.vfs2.provider.UriParser.extractScheme(String)}}
* {{org.apache.commons.vfs2.provider.UriParser.extractScheme(String,
StringBuilder)}}
The callers of these APIs must be updated to the new APIs. If not, you must
rethink the need and/or usage of the new vs. old APIs...
Thank you,
Gary
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DIGESTER-190) Incorrect Symbolic Name Causing Module Creation Error In Apache Netbeans
[
https://issues.apache.org/jira/browse/DIGESTER-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711787#comment-16711787
]
Sumner R commented on DIGESTER-190:
---
Geertjan,
I checked NETBEANS-1616 and no one to date has been assigned. I can not
proceed on this major piece of my software without it being resolved. Can you
provide me with an estimate as to its position in the pipeline?
Sent from Sumner Andrews
From: Geertjan Wielenga (JIRA)
Sent: Tuesday, November 6, 2018 10:09 AM
To: sumner_andr...@yahoo.com
Subject: [jira] [Commented] (DIGESTER-190) Incorrect Symbolic Name
CausingModule Creation Error In Apache Netbeans
[
https://issues.apache.org/jira/browse/DIGESTER-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677016#comment-16677016
]
Geertjan Wielenga commented on DIGESTER-190:
Can you provide detailed step by step instructions so someone can reproduce
this and analyze for fixing?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
> Incorrect Symbolic Name Causing Module Creation Error In Apache Netbeans
>
>
> Key: DIGESTER-190
> URL: https://issues.apache.org/jira/browse/DIGESTER-190
> Project: Commons Digester
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: Sumner R Andrews Jr
>Priority: Major
> Fix For: 3.2
>
> Attachments: 1CE4EA92ADF641068A09EA4A2B95C338.jpg,
> 438AA1DCF0B24A478907548529405C9F.jpg, 4BBE97D2EB3C423EB49F95C83CC3778B.jpg,
> 6363FA99752D4D6BAEC9D6DA89FD07AA.jpg, 94449B5801D248FDB232B0EDCE18C013.jpg,
> 992A84F8902C497292DB62AF9A0888B8.jpg
>
>
> In my Netbeans 9 project, I attempted to add Digester and Lang 3 as Jigsaw
> modules. Both were added to the module path by Netbeans via a wizard
> module XmlTrans {
> requires opencsv;
> requires org.apache.commons.lang3;
> requires commons.digester;
> }
> However, the project produced the following error when compiled:
> Compiling 14 source files to
> /home/sumner/JNB/NetBeansProjectsPre9.0/Applications/XmlTrans/build/classes
> /home/sumner/JNB/NetBeansProjectsPre9.0/Applications/XmlTrans/src/module-info.java:10:
> error: module not found: commons.digester
> requires commons.digester;
> 1 error
> BUILD FAILED (total time: 1 second)
> It is not possible to change the statement “requires commons.digester” to
> “org.apache.common.digester3” to correct the problem.
> Interestingly, both libraries use the same org.apache.commons directory
> structure in their jars with the library name at the end as .digester3 and
> .lang3 respectively.
> A comparison of the MANAFEST.MFs however reveals the potential problem. In
> the case of Lang3 the manifest lists:
> Automatic-Module-Name: org.apache.commons.lang3
> Bundle-SymbolicName: org.apache.commons.lang3
> Whereas the Digester manifest only references:
> Bundle-SymbolicName: org.apache.commons.digester
>
> Obviously, the error lies with the digester manifest.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DAEMON-395) Fix hash links on download page
[ https://issues.apache.org/jira/browse/DAEMON-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711687#comment-16711687 ] Sebb commented on DAEMON-395: - The PGP links work for me. However the MD5 links are broken; the hash has been replaced by SHA256 or SHA512 Fixed on the production copy of the website. TODO fix the source > Fix hash links on download page > --- > > Key: DAEMON-395 > URL: https://issues.apache.org/jira/browse/DAEMON-395 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.15 >Reporter: Neil >Priority: Major > > No data is returned from the Download page when clicking on MD5 or PGP links > for file entries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DAEMON-395) Fix hash links on download page
[ https://issues.apache.org/jira/browse/DAEMON-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-395: Summary: Fix hash links on download page (was: Provide MD5 and PGP data for links on download page) > Fix hash links on download page > --- > > Key: DAEMON-395 > URL: https://issues.apache.org/jira/browse/DAEMON-395 > Project: Commons Daemon > Issue Type: Improvement > Components: Jsvc >Affects Versions: 1.0.15 >Reporter: Neil >Priority: Major > > No data is returned from the Download page when clicking on MD5 or PGP links > for file entries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711584#comment-16711584
]
Gary Gregory commented on FILEUPLOAD-279:
-
FWIW: I published a new {{1.4-SNAPSHOT}} to
https://repository.apache.org/content/repositories/snapshots/commons-fileupload/commons-fileupload/
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to read in the file
> from disk.
> That filename is always generated via getOutputStream.
> Serialized Object
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711520#comment-16711520
]
Jochen Wiedmann commented on FILEUPLOAD-279:
Bernd,
indeed, the fix for master / 1.4 is different: In the future version, we didn't
bother with binary compatibility. So, we simply let FileItem no longer
implement java.io.Serializable. In the 1.3 branch, bc matters. So we check for
a system property, and throw an exception at runtime.
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
> at the time of serialization in order for successful deserialization to occur.
> If
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711476#comment-16711476
]
Gilles commented on FILEUPLOAD-279:
---
bq. ASF bylaws makes it hard to offer snapshots
?
Jenkins produces them after a successful build.
bq. we should not do it.
Why?
They come with all the caveats: Not an official release, thus no support
whatsoever.
However, they might be helpful to *us* by providing an easy way for users to
test the latest artefacts (and, hopefully, report problems).
bq. Should we discuss this on the users or dev mailing list?
Probably. ;-)
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711420#comment-16711420
]
Bernd Eckenfels commented on FILEUPLOAD-279:
ASF bylaws makes it hard to offer snapshots and I would agree that we should
not do it. (if there is a good reason for users to request 1.4 snapshots it
might be time for a release?). Should we discuss this on the users or dev
mailing list?
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711417#comment-16711417
]
Gilles commented on FILEUPLOAD-279:
---
bq. AFAIK, we do not offer automated snapshot builds
Some components do, through Jenkins; see e.g.
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-rng-sampling/1.2-SNAPSHOT/
but the lack of synergies between components' maintenance tasks makes it
difficult to have up-to-date configurations that produce artefacts in a timely
manner and at expected places...
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711398#comment-16711398
]
Jochen Wiedmann commented on FILEUPLOAD-279:
Rasmita,
as I have no idea, who created that file, when, and how, I couldn't really
tell. All I can say: The fix was committed on 12-May-2016, 13:39 UTC. (See
[https://git-wip-us.apache.org/repos/asf?p=commons-fileupload.git;a=commitdiff;h=02f6b2c4ef9aebf9cf8e55de8b90e73430b69385]
for details.) Or, in other words: Any version, properly created from the
genuine source tree after that point, should be safe. AFAIK, we do not offer
automated snapshot builds, so your only choice is to build a snapshot for
yourself.
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call
[jira] [Comment Edited] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711401#comment-16711401
]
Bernd Eckenfels edited comment on FILEUPLOAD-279 at 12/6/18 12:52 PM:
--
[~joc...@apache.org] I dont think thats entirely correct, I dont see the
orifginal system-property changes in the master file and the changes.xml is
messed up. Is the 1.4 branch supposed to have a "different" solution than
_this_ 1.3.3 fix?
was (Author: b.eckenfels):
[~joc...@apache.org] I dont think thats correct, I dont see the changes in the
master file and the changes.xml is messed up. The master branch looks borken to
me.
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711401#comment-16711401
]
Bernd Eckenfels commented on FILEUPLOAD-279:
[~joc...@apache.org] I dont think thats correct, I dont see the changes in the
master file and the changes.xml is messed up. The master branch looks borken to
me.
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to read in the file
> from disk.
> That filename is always generated via
[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711376#comment-16711376
]
Bernd Eckenfels commented on FILEUPLOAD-279:
[~rasmita] it looks like the fix is missing in master/b1_4.
(There are other problems with the master, like a broken changes.xml). I would
think sticking with 1.3.3 is better until a official 1.4 release.)
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not
> serialized. dfos is regenerated by the getOutputStream() call above (which
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to read in the file
> from disk.
> That
[jira] [Comment Edited] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
[
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710987#comment-16710987
]
Rasmita Mahapatra edited comment on FILEUPLOAD-279 at 12/6/18 9:58 AM:
---
Is this bug fix is ported to 1.4 SNAPSHOT build.
We are currently using _commons-fileupload-1.4-20160119.063138-53. Is this
security bug is fixed in this build or we have to upgrade to some other build,
please suggest._
_If this issue is fixed in 1.4, please point me to the build location from
where I can pick the jar_
was (Author: rasmita):
Is this bug fix is ported to 1.4 SNAPSHOT build.
We are currently using _commons-fileupload-1.4-20160119.063138-53. Is this
security bug is fixed in this build or we have to upgrade to some other build,
please suggest._
> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
> Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can
> be manipulated in such a way that when it is deserialized, it can write or
> copy files to disk in arbitrary locations. Furthermore, while the Object can
> be used alone, this new vector can be integrated with ysoserial to upload and
> execute binaries in a single deserialization call. This may or may not work
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s
> yososerial tool to gain remote code execution on a variety of commercial
> products, based on a presentation at AppSec Cali in January, 2015. The
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and
> Spring that do “unexpected” things during deserialization. Specifically, the
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make
> “it easy to add robust, high-performance, file upload capability to your
> servlets and web applications.” One of the classes in the FileUpload library
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads.
> Interestingly, DiskFileItem is serializable and implements custom
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the
> JVMs are
> 639 * on different machines It is possible that the repository
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after
> analyzing the state of DiskFileItem after serialization it became clear that
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is
