[jira] [Commented] (CONFIGURATION-731) Allow user to specify the comments & separator chars
[ https://issues.apache.org/jira/browse/CONFIGURATION-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706624#comment-16706624 ] Shuai Zhang commented on CONFIGURATION-731: --- Hi [~oliver.he...@t-online.de] & [~garydgregory], Would you help to review & merge it? Regards, Shuai Zhang > Allow user to specify the comments & separator chars > > > Key: CONFIGURATION-731 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-731 > Project: Commons Configuration > Issue Type: Improvement > Components: Format >Affects Versions: 2.4 >Reporter: Shuai Zhang >Priority: Major > Attachments: CONFIGURATION-731.001.patch, > CONFIGURATION-731.002.patch, CONFIGURATION-731.003.patch > > > Currently the INIConfiguration defined comments & separator chars as final > static fields, which made it impossible for the user control the behavior of > INIConfiguration parsing. I suggest making them as default value, open setter > & getter methods for the comment & separator chars. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang pull request #391: Adding junits for JsonToStringStyle
GitHub user RahulNagekar reopened a pull request: https://github.com/apache/commons-lang/pull/391 Adding junits for JsonToStringStyle You can merge this pull request into a Git repository by running: $ git pull https://github.com/RahulNagekar/commons-lang JsonToStringStyle_Junits Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/391.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #391 commit 45c096440785e00ade613aee2d7a2fef6f17ca8c Author: RahulNagekar Date: 2018-11-28T19:54:43Z Add additional tests for StandardToStringStyle (closes #390) commit 77bd11f0d69608829e26b2a6420561620df83941 Author: RahulNagekar Date: 2018-12-02T20:15:54Z Adding junits for JsonToStringStyle ---
[GitHub] commons-lang pull request #391: Adding junits for JsonToStringStyle
Github user RahulNagekar closed the pull request at: https://github.com/apache/commons-lang/pull/391 ---
[GitHub] commons-lang issue #391: Adding junits for JsonToStringStyle
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/391 [](https://coveralls.io/builds/20408483) Coverage increased (+0.3%) to 95.53% when pulling **211a7c2031d70612ac859a3d046d819f1f9211bc on RahulNagekar:JsonToStringStyle_Junits** into **c368955343029d1a99d1b6817eb9fef0c62f02d3 on apache:master**. ---
[GitHub] commons-lang pull request #391: Adding junits for JsonToStringStyle
GitHub user RahulNagekar opened a pull request: https://github.com/apache/commons-lang/pull/391 Adding junits for JsonToStringStyle You can merge this pull request into a Git repository by running: $ git pull https://github.com/RahulNagekar/commons-lang JsonToStringStyle_Junits Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/391.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #391 commit 211a7c2031d70612ac859a3d046d819f1f9211bc Author: RahulNagekar Date: 2018-12-02T20:15:54Z Adding junits for JsonToStringStyle ---
[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=16706448#comment-16706448
]
Jochen Wiedmann commented on FILEUPLOAD-279:
Adam,
I do not feel responsible for external sites like cvedetails.com. To me, the
authoritative information is available from
[https://commons.apache.org/proper/commons-fileupload/download_fileupload.cgi]
and
[https://commons.apache.org/proper/commons-fileupload/security-reports.html#Apache_Commons_FileUpload_Security_Vulnerabilities]
which both completely match, what I am saying.
> 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
[GitHub] commons-lang pull request #390: Adding junits for StandardToStringStyle
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/390 ---
[GitHub] commons-lang issue #390: Adding junits for StandardToStringStyle
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/390 Thanks! ---
[GitHub] commons-lang issue #390: Adding junits for StandardToStringStyle
Github user RahulNagekar commented on the issue: https://github.com/apache/commons-lang/pull/390 > Thank for the contribution. > > Could you please squash to the commits? Then I will merge the pull request. Done :-) ---
[jira] [Commented] (TEXT-126) Dice's Coefficient Algorithm in String similarity
[ https://issues.apache.org/jira/browse/TEXT-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706274#comment-16706274 ] Pascal Schumacher commented on TEXT-126: Contributions welcome! > Dice's Coefficient Algorithm in String similarity > - > > Key: TEXT-126 > URL: https://issues.apache.org/jira/browse/TEXT-126 > Project: Commons Text > Issue Type: Improvement >Reporter: Vicky Chawda >Priority: Major > > I'd like to propose an extension to the algorithms for string similarity in > *commons-text/src/main/java/org/apache/commons/text/similarity/* > Dice's Coefficient Algorithm can be helpful for many who are looking for > ranking similarities in strings. > *Inspired from* - [http://www.catalysoft.com/articles/StrikeAMatch.html] -- 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=16706189#comment-16706189
]
Adam Pikulik commented on FILEUPLOAD-279:
-
Jochen,
Thank you for replying so quickly. I am asking because in the affected versions
I see only 1.3.2 and also under the link:
[https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-24746/version_id-143021/Apache-Commons-Fileupload-1.2.html]
this CVE is not listed. Just got confused if before means only 1.3.2 or all
versions before.
Thank you very much!
Adam
> 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
[GitHub] commons-lang issue #390: Adding junits for StandardToStringStyle
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/390 Thank for the contribution. Could you please squash to the commits? Then I will merge the pull request. ---
[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=16706178#comment-16706178
]
Jochen Wiedmann commented on FILEUPLOAD-279:
*Exactly,* as is written in your quote, and in my comment above: Version 1.3.3
is *not* affected. All previous versions are. Why are you asking?
> 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] (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=16706163#comment-16706163
]
Adam Pikulik commented on FILEUPLOAD-279:
-
Hello,
There is "Affected versions: 1.3.2" however on other websites like:
[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-131]
[https://nvd.nist.gov/vuln/detail/CVE-2016-131
]
all versions before 1.3.3 are vulnerable. What versions are impacted by this
bug?
Thanks,
Adam
> 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
