[jira] [Commented] (GEOMETRY-23) Remove Euclidean Point Classes
[ https://issues.apache.org/jira/browse/GEOMETRY-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677673#comment-16677673 ] Matt Juntunen commented on GEOMETRY-23: --- I am positive that our primary vector/point classes should use Cartesian coordinates as a matter of convention. Other coordinate systems should be (and currently are) supported but any coordinate conversions should be explicitly called out in the API. I don't see any practical benefit to creating another layer of abstraction here. > Remove Euclidean Point Classes > -- > > Key: GEOMETRY-23 > URL: https://issues.apache.org/jira/browse/GEOMETRY-23 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > > Based on discussion of the current Point/Vector API in GEOMETRY-14 and > research into other geometric libraries, I think we should remove the > Euclidean Point?D classes and make Vector?D also implement Point. This will > end up being similar to the previous commons-math design but avoids the issue > raised in MATH-1284 since the Point and Vector interfaces are not related. > They just happen to be implemented by the same class, which we're calling > Vector?D since a vector can be used to indicate a point (by adding it to the > origin). > In the course of trying this out this design, I ended up removing 7 classes > and simplifying several methods. I think that's a good indicator that this is > a good design choice. > > Pull request: https://github.com/apache/commons-geometry/pull/15 -- 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=16677464#comment-16677464
]
jack commented on FILEUPLOAD-279:
-
If you can't upgrade, what things should you monitor to reduce the risk of this
being exploited. System is going to be EOL soon, however, it is still critical
and an upgrade isn't viable.
> 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=16677377#comment-16677377
]
Bernd Eckenfels commented on FILEUPLOAD-279:
The „safe“ thing to do is, if you are in doubt then assume you need to upgrade
to not be vulnerable. (And it reduces the amount of justification and
explaining you have to do when you are regularly bombarded with scan reports
and requests for asking for exceptions to keep old, known vulnerable versions
around)
> 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
[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=16677267#comment-16677267
]
Matt Kempers commented on FILEUPLOAD-279:
-
What is the best way to find this vulnerability across environment?
Is it safe to say any version of commons-fileupload pre 1.3.* on Struts 1 &2 is
vulnerable?
> 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.
>
[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=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?
> 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
>
>
> 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] (VFS-674) Cannot close an FTP input stream without an exception
[
https://issues.apache.org/jira/browse/VFS-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676880#comment-16676880
]
Boris Petrov commented on VFS-674:
--
I've added a pull-request that fixes this:
https://github.com/apache/commons-vfs/pull/41
> Cannot close an FTP input stream without an exception
> -
>
> Key: VFS-674
> URL: https://issues.apache.org/jira/browse/VFS-674
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Boris Petrov
>Priority: Critical
>
> The FTP server is FileZilla.
> 1. Get a stream instance from an FtpFileObject via the `getInputStream`
> method.
> 2. Read some bytes from the stream.
> 3. Close the stream via `stream.close()`.
> 4. If the stream has not been completely read, the FTP server sends a `426
> Connection closed; transfer aborted` response code.
> 5. `FtpFileObject::onClose` is called.
> 6. Eventually `FTPReply::isPositiveCompletion` is called.
> 7. Since the response code is outside the [200; 300) range it is considered
> an error.
> 8. A `FileSystemException` is thrown.
> The overall result is that when closing a stream that is not completely read
> an exception is thrown. Which is obviously wrong.
> A similar things happens with this piece of code:
> {code:java}
> try (FileContent content = ftpFileObject.getContent()) {
> // ..
> }
> {code}
> Is there an easy way we can patch this in VFS as this is a showstopper for us?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
