Edit report at http://pear.php.net/bugs/bug.php?id=18505&edit=1

ID: 18505
Comment by: mariusads@helpedia.com
Reported By: mariusads at helpedia dot com
Summary: Possible incorrect handling of file names in TAR
Status: Open
Type: Bug
Package: Archive_Tar
Operating System: Irrelevant
Package Version: SVN
PHP Version: Irrelevant
Roadmap Versions:
New Comment:


Perhaps in the case of long file names, the actual size field should
also be double checked.

As that field contains 11 bytes of data, someone could hack a tar file
to enter there the maximum value possible in Octal - 77.777.777.777 or
float(8589934591) - the result of Octdec would be a float value since
the value is bigger than 32 bit integer, so value / 512 would give you
float(16777215) but value % 512 would result in -1, which would make the
_readLongHeader read an extra 512 byte of data because -1 != 0

But it's a bit silly anyway, though one could gzip/bz2 8 GB of nulls in
a few hundred KB just to mess with some websites using this script.

Previous Comments:

[2011-05-05 01:11:50] mariushm

I'm looking over the code to see how long file names are handled and
couldn't help notice both in the stable version and the SVN the
following code:

function _readLongHeader(&$v_header)
1417 {
1418 $v_filename = '';
1419 $n = floor($v_header['size']/512);
1420 for ($i=0; $i<$n; $i++) {
1421 $v_content = $this->_readBlock();
1422 $v_filename .= $v_content;
1423 }
1424 if (($v_header['size'] % 512) != 0) {
1425 $v_content = $this->_readBlock();
1426 $v_filename .= trim($v_content);
1427 }

I assume this section runs after the code detects a 512 byte chunk of
"L" type ("/./@LongLink"), and retrieves the long file name.

I don't think trim is the right function to use there on the last chunk,
because besides 0x00 bytes, it actually trims 6 character codes (spaces,
newlines, tabs,nulls).

From these, all but 0x00 are valid characters on a Linux system and can
be used anywhere in a file name, including right at the end.

Windows is more sensitive about it, but while uncommon, it's possible
for a file name in Windows to end with a "space" character, and the
other characters could also have some meaning if file names are in
Unicode (or for example if someone uses \\?\c:\[very long path] - a
sanctioned by Microsoft method to go around Windows limitations
regarding long paths)

Basically, substr should be used, especially since the full length of
the file name is known.

Also, in the regular function "_readHeader", I don't see the file name
actually reduced to its actual length by removing the nulls at the end.
Though I'm not sure if this is a problem - too busy to test now if PHP
automatically removes the null bytes at the end of the string or not.

Test script:
No test script

Expected result:
Don't expect anything as there's no script


Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
postedMay 5, '11 at 12:25a
activeMay 5, '11 at 12:25a

1 user in discussion

Mariusads: 1 post



site design / logo © 2022 Grokbase