From issues-return-70942-archive-asf-public=cust-asf.ponee.io@commons.apache.org Thu Dec 6 11:09:13 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id B8677180674 for ; Thu, 6 Dec 2018 11:09:12 +0100 (CET) Received: (qmail 24879 invoked by uid 500); 6 Dec 2018 10:09:11 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 24868 invoked by uid 99); 6 Dec 2018 10:09:11 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Dec 2018 10:09:11 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 3F9B3CBCB7 for ; Thu, 6 Dec 2018 10:09:11 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -109.501 X-Spam-Level: X-Spam-Status: No, score=-109.501 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id EB0pbnh3EWIH for ; Thu, 6 Dec 2018 10:09:07 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 8801B610EC for ; Thu, 6 Dec 2018 09:59:02 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 621BBE2637 for ; Thu, 6 Dec 2018 09:59:01 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 90230252CE for ; Thu, 6 Dec 2018 09:59:00 +0000 (UTC) Date: Thu, 6 Dec 2018 09:59:00 +0000 (UTC) From: "Rasmita Mahapatra (JIRA)" To: issues@commons.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=3Dcom.atlas= sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D= 16710987#comment-16710987 ]=20 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=C2=A0_commons-fileupload-1.4-20160119.063138-53. Is = this security bug is fixed in this build or we have to upgrade to some othe= r 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=C2=A0_commons-fileupload-1.4-20160119.063138-53. Is = this security bug is fixed in this build or we have to upgrade to some othe= r build, please suggest._ > CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulati= on 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 Objec= t can be used alone, this new vector can be integrated with ysoserial to up= load and execute binaries in a single deserialization call. This may or may= not work depending on an application's implementation of the FileUpload li= brary. > Background > In late 2015 FoxGlove Security released a write up on using Chris Frohoff= =E2=80=99s yososerial tool to gain remote code execution on a variety of co= mmercial products, based on a presentation at AppSec Cali in January, 2015.= The ysoserial tool uses =E2=80=9Cgadgets=E2=80=9D in Apache Commons Collec= tions, Groovy, and Spring that do =E2=80=9Cunexpected=E2=80=9D things durin= g deserialization. Specifically, the ysoserial payloads eventually execute = Runtime.getRuntime().exec() allowing for remote Java code execution. > The Apache Commons project maintains a library called =E2=80=9CFileUpload= =E2=80=9D to make =E2=80=9Cit easy to add robust, high-performance, file up= load capability to your servlets and web applications.=E2=80=9D One of the = classes in the FileUpload library is called =E2=80=9CDiskFileItem=E2=80=9D.= A DiskFileItem is used to handle file uploads. Interestingly, DiskFileItem= is serializable and implements custom writeObject() and readObject() funct= ions. > DiskFileItem=E2=80=99s readObject Implementation > Here is the implementation that currently exists at the projects reposito= ry tip (as of 1/28/16): > 632 private void readObject(ObjectInputStream in) > 633 throws IOException, ClassNotFoundException { > 634 // read values > 635 in.defaultReadObject(); > 636 > 637 /* One expected use of serialization is to migrate HTTP sessio= ns > 638 * containing a DiskFileItem between JVMs. Particularly if the= JVMs are > 639 * on different machines It is possible that the repository lo= cation is > 640 * not valid so validate it. > 641 */ > 642 if (repository !=3D null) { > 643 if (repository.isDirectory()) { > 644 // Check path for nulls > 645 if (repository.getPath().contains("\0")) { > 646 throw new IOException(format( > 647 "The repository [%s] contains a null chara= cter", > 648 repository.getPath())); > 649 } > 650 } else { > 651 throw new IOException(format( > 652 "The repository [%s] is not a directory", > 653 repository.getAbsolutePath())); > 654 } > 655 } > 656 > 657 OutputStream output =3D getOutputStream(); > 658 if (cachedContent !=3D null) { > 659 output.write(cachedContent); > 660 } else { > 661 FileInputStream input =3D new FileInputStream(dfosFile); > 662 IOUtils.copy(input, output); > 663 IOUtils.closeQuietly(input); > 664 dfosFile.delete(); > 665 dfosFile =3D null; > 666 } > 667 output.close(); > 668 > 669 cachedContent =3D null; > 670 } > This is interesting due to the apparent creation of files. However, after= analyzing the state of DiskFileItem after serialization it became clear th= at arbitrary file creation was not supposed to be intended: > dfos (a type of OutputStream) is transient and therefore it is not serial= ized. dfos is regenerated by the getOutputStream() call above (which also g= enerates the new File to write out to). > The =E2=80=9Crepository=E2=80=9D (or directory that the file is written t= o) has to be valid at the time of serialization in order for successful des= erialization to occur. > If there is no =E2=80=9CcachedContent=E2=80=9D 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 not take into account that someone might modify= the serialized data before it is deserialized. Three important elements ge= t serialized that we can modify: > The repository path (aka the directory that the file is read/written from= ). > If there is cachedContent (i.e. data that didn=E2=80=99t get written to t= he file) then that gets serialized > If there is no cachedContent (i.e. all data was written to disk) the full= path to the output file exists. > The threshold value that controls if =E2=80=9CcachedContent=E2=80=9D is w= ritten to disk or not. > Modifying these three elements in the serialized object gives us the abil= ity to: > Create files wherever we have permission on the system. The caveat here i= s that we only have control of the file path and not the final filename. > Copy the contents of files from one file on the system to a location we s= pecify (again we only control the directory path and not the filename). Thi= s will also attempt to delete the file we copy from.. so be careful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)