[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&focusedCommentId=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 [![Coverage Status](https://coveralls.io/builds/20408483/badge)](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&focusedCommentId=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 fi
[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&focusedCommentId=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&focusedCommentId=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
[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&focusedCommentId=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 getOutpu
[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&focusedCommentId=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