Did you compile PHP from source or did you use the ports? If you used the ports, can you check what patches were applied to the clean php source?

Our web host, pair Networks, installed the PHP version to the server. I believe they compiled from source, and I know they are experts at installing and configuring PHP as they manage hundreds of servers.

From a phpinfo() command here are the configure command options they used on Aug 18/04:

'./configure' '--with-apache=/usr/pair/sw/apache_1.3.29' '--with-config-file-path=/usr/local/etc' '--enable-magic-quotes' '--enable-bcmath' '--without-cdb' '--with-zlib-dir=/usr/local' '--with-gd' '--with-ttf' '--without-msql' '--with-mysql=/usr/local' '--with-iodbc' '--with-pdflib' '--enable-inline-optimization' '--disable-memory-limit' '--with-db' '--without-gdbm' '--with-ndbm' '--without-db2' '--without-dbm' '--with-gettext' '--without-readline' '--with-recode' '--without-openssl' '--with-mcrypt' '--without-db3' '--enable-dba' '--with-curl' '--with-png-dir=/usr/local/lib' '--with-jpeg-dir=/usr/local/lib' '--enable-calendar' '--with-mhash' '--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local' '--enable-gd-lzw-gif' '--enable-mstring'

It might have something to do with this bug fix: http://bugs.php.net/bug.php?id=28456

Yes it probably is related to that "fix" BUT this "fix" breaks a ton of code and changes the behavior. Can the "fix" be done in such a way that it prevents the security vulnerability, but doesn't break all the existing code out there that needs the client path of file(s) being uploaded?

Also before this new fix is fixed, is there any workaround?

Which path is this, of the original uploaded file name or the one on the server (in /tmp...)?

It is the path of the original uploaded file name. The reason this info is needed, is when a bunch of files are uploaded via a web file manager application, it needs to know the path of each file, so when it re-creates the path/file structure on the server, it is able to put all the files in the right places, rather than everything going in "one directory".

I don't think the RFC actually allows that, nor was this ever documented. I will check the RFC later.

It was not documented, but this has been the well-known behavior for quite some time, and the browsers do send the path information. Any code written to deal the the 'name' value has always had to deal with the path information, so changing it now breaks all code from previous versions. Perhaps the new behaviour default could be to only get the filename, but an override would allow us to get the path too? Just some way so that old written systems will still be able to work =)

Let me clarify a bit...  we use a tool from Radinks, and in this tool there is a "FULL_PATH" option that will pass along the full path and filename in the $_FILES['..']['name'] variable.  By default, it's just the filename in this ['name'] variable, but Radinks did something (possibly in headers?) to allow the fullpath to come through.  It looks as though the security "fix" broke this desired behavoiur.

RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

lists:
15.5 Content-Disposition Issues

RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details.


RFC 2388 "Returning Values from Forms:  multipart/form-data"
Lists:

"multipart/form-data" contains a series of parts. Each part is expected to contain a content-disposition header [RFC 2183] where the disposition type is "form-data", and where the disposition contains an (additional) parameter of "name", where the value of that parameter is the original field name in the form. For example, a part might contain a header:

        Content-Disposition: form-data; name="user"

with the value corresponding to the entry of the "user" field.

Field names originally in non-ASCII character sets may be encoded within the value of the "name" parameter using the standard method described in RFC 2047.



RFC 2183 "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"

lists in 2.3:

The receiving MUA SHOULD NOT respect any directory path information that may seem to be present in the filename parameter.  The filename should be treated as a terminal component only.  Portable specification of directory paths might possibly be done in the future via a separate Content-Disposition parameter, but no provision is made for it in this draft.



So the current behavior is correct and advocated by the RFCs. PHP's handling of filenames will not be changed.