Project

General

Profile

Actions
Copy link

Bug #24030

closed

Directory traversal attack in em_unzip

Added by Anthon Pang about 14 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Benni Mack
Category:
-
Target version:
-
Start date:
2010-11-12
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.4
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

typo3/mod/tools/em/class.em_unzip.php is a fork of an old version of PclZip. The latest version of PclZip is 2.8.2 and has a number of fixes (eg 64-bit support) and security enhancements.

em_unzip.php handles absolute paths in the .zip archive but not relative paths containing '../' thus allowing files to be extracted outside of the target directory. To prevent this, PclZip 2.5 introduced PCLZIP_OPT_EXTRACT_DIR_RESTRICTION to set a basedir. Note: there's a bug where it can be bypassed if the extracted basedir is supplied as an absolute path. (See attached patch against PclZip 2.8.2 for a fix.)

Reporter: Anthon Pang
OTRS: 2010111210000026
(issue imported from #M16362)

Files

Download all files
16362_trunk.patch (574 Bytes) 16362_trunk.patch Administrator Admin, 2010-12-09 21:16
16362_44.patch (451 Bytes) 16362_44.patch Administrator Admin, 2010-12-09 21:17
16362_43.patch (451 Bytes) 16362_43.patch Administrator Admin, 2010-12-09 21:17
16362_42.patch (451 Bytes) 16362_42.patch Administrator Admin, 2010-12-09 21:17
Actions
Copy link
 #1

Updated by Steffen Gebert about 14 years ago

Thanks for the report. Did you report this to ?

Actions
Copy link
 #2

Updated by Anthon Pang about 14 years ago

No, I didn't know there was an email address to report the issue.

p.s. ignore the attached file. It has side effects when not used with ARCHIVE_ZIP_PARAM_PATH (aka PCLZIP_OPT_PATH).

What I did in Piwik was to use PCLZIP_CB_PRE_EXTRACT, defining a callback function to examine each path and return an appropriate result code. A similar fix could be applied to typo3/sysext/tsconfig_help/mod1/index.php's unzip().

Reference: http://dev.piwik.org/trac/changeset/3311

Actions
Copy link
 #3

Updated by Steffen Gebert about 14 years ago

Thanks for the update. Please report it to the security team, which will take further investigations and steps to fix the issue.

Actions
Copy link
 #4

Updated by Benni Mack almost 14 years ago

I've prepared a patch and a use-case. For that I created a zip file with relative paths.

The dangerous zip file includes the following files:
$ zipinfo dangerous.zip
Archive: dangerous.zip 3468 bytes 5 files
rw-r--r- 3.0 unx 1163 tx defN 9-Dec-10 21:12 testfile_5.txt
rw-r--r- 3.0 unx 1163 tx defN 9-Dec-10 21:11 ../testfile_4.txt
rw-r--r- 3.0 unx 1163 tx defN 8-Dec-10 15:36 ../../testfile_3.txt
rw-r--r- 3.0 unx 1163 tx defN 8-Dec-10 15:36 ../../../testfile_2.txt
rw-r--r- 3.0 unx 1163 tx defN 8-Dec-10 15:36 ../../../../testfile.txt
5 files, 5815 bytes uncompressed, 2610 bytes compressed: 55.1%

Now, the only issue where this happens in the core is in the "tsconfig_help" module when rebuilding the new manuals. This works like this:

- The manuals of each installed extension (.sxw is just a zip file btw) get extracted by the EXT:tsconfig_help/mod1/index.php and only the file "contents.xml" gets loaded into a string. For that, the module extracts all files of the manual.sxw

To reproduce: 

- Take the dangerous.zip file and move it to docs/manual.sxw of any installed extension on your TYPO3 installation.
- Then go to the tsconfig_help module and rebuild the index. The testfiles should be outside of your main TYPO3 installation.

The patch disallows .. files and thus solves the whole issue directly in the unzip class.

Actions
Copy link
 #5

Updated by Benni Mack about 6 years ago

  • Status changed from Resolved to Closed
Actions
Copy link

Also available in: Atom PDF