Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

[R4] Apache Wicket DiskFileItem Java Deserialization Remote File Manipulation

Medium

Synopsis

Apache Wicket is "an open source, component oriented, server-side, Java web application framework." Currently, main development of Wicket is done on the 8.x branch. However, Wicket’s website indicates the current release is listed as 7.3.0 and they continue to offer 6.23.0 as well as 1.5.14.

The Issue

Wicket 6.x contains an implementation of a Java Class called “DiskFileItem that is nearly identical to the Commons Upload previously disclosed in TRA-2016-12. The only real difference being that the Commons Upload version has been updated to address issues such as CVE-2013-2186 where the Wicket version has not. Fortunately, most (if not all) JVM will catch this attack so it no longer needs to be explicitly checked for as done in Commons Fileupload. Interestingly, DiskFileItem was purged from the 7.x branch back in 2014 as a result of the WICKET-5503 ticket as seen in commit 99fcd91. The developers correctly identified that tracking security updates in Commons FileUpload was too difficult (since they already missed the update to DiskFileItem).

Can This Be Used In Deserialization Attacks?

Of course! As a quick proof of concept, Tenable created a new payload in ysoserial and it is almost an exact copy/paste job of the FileUpload1 payload but uses wicket-util. This allows an attacker to add, move, and delete files that Apache DiskFileItem can. Additionally, if an older Java VM is running, the attacker can control the filename as well, since the NULL byte check doesn't exist. In that case, the ability to name and place a custom file can lead to remote code execution.

Note that the CVSSv2 score downplays the severity of this issue due to the academic nature of the scoring system. Worst case scenario, this can be leveraged to achieve remote code execution in some cases through several actions.


On 2016-11-25, the Wicket team contacted us again and mentioned that they missed an important point in our original report to them: "Protect against null byte attacks". Pedro Santos from the Wicket team dug into this even further and committed additional fixes and write-up. His analysis concludes this is specific to Wicket and had CVE-2016-6793 assigned for it. More details will be published via Wicket's page on this issue in the near future.

Solution

The Apache Wicket team has released versions 6.24.0 and 1.5.16 that resolve this issue.

Disclosure Timeline

2016-05-05 - Issue Discovered
2016-05-23 - Issue reported to vendor at security@apache.org
2016-05-24 - Vendor asks for PoC
2016-05-25 - Tenable sends PoC
2016-05-25 - Vendor says "not so familiar with the problem" asks for more information
2016-05-25 - Tenable sends extensive write-up explaining Deserialization attacks/issues
2016-05-26 - Vendor doubts this is a vulnerability in Wicket
2016-05-26 - Tenable sends another write-up explaining they are technically correct, but like Commons, it can be tragic for developers. Implementing additional safeguards is trivial and does not impact the software.
2016-05-27 - Vendor agrees with our assessment.
2016-06-08 - Vendor makes changes in Git to address the issue. Fix will be included in 1.5.16 and 6.24.0.
2016-07-07 - Tenable confirms those changes should fix the issue.
2016-07-20 - Wicket releases 6.24.0 and 1.5.16 but doesn't inform Tenable.
2016-07-25 - Tenable realizes Wicket released a new version and confirmed the fixes.
2016-08-07 - Gregory Draperi posts a blog about same issue
2016-12-31 - Vendor posts advisory / update

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email advisories@tenable.com