[wp-trac] [WordPress Trac] #26626: WP_Upgrader::unpack_package() can overflow path name length limits (patch attached)
WordPress Trac
noreply at wordpress.org
Fri Mar 7 22:57:33 UTC 2014
#26626: WP_Upgrader::unpack_package() can overflow path name length limits (patch
attached)
------------------------------------+------------------------------
Reporter: DavidAnderson | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Upgrade/Install | Version: trunk
Severity: normal | Resolution:
Keywords: has-patch dev-feedback | Focuses:
------------------------------------+------------------------------
Comment (by DavidAnderson):
Thanks for the feedback. I'm attaching a new patch that cuts out md5() and
just uses substr( ..., 0, 32).
This isn't an extreme edge case - I've seen pathname overflows happen in 3
different ways (the most recently was a few days ago):
1) For packages downloaded over HTTP, basename($package), $package ends up
as being a temporary folder followed by basename() on the URL that the
package was fetched from. I had a plugin downloading from a URL like this:
http://example.com/?udm_action=download&slug=whatever&muid=1&token=2ffd3c5308ca075df83f8b53717efbac
basename() on that is
?udm_action=download&slug=whatever&muid=1&token=2ffd3c5308ca075df83f8b53717efbac
- 80 characters long. I got a number of support requests on that... I then
fixed it by the kludge of adding an extra URL parameter on the end of the
URL the updates server was offering up that contained a / so that
basename() cut from there.
2) The case given in the bug report, multiple times. An 80-character zip
filename was enough to cause it. But, it'd be easy to get cases with a
shorter one. Some Windows users love long directory names - I've seen
stuff like "Copy of the website for the meeting next Friday". Add on
C:\Users\Smith Family\Our Company\Website Development\Clients\AcmeCo - and
256 is getting pretty easy to hit. That's not theory - I've had plenty of
support requests from ones like that.
3) I added a copy of the Rackspace SDK to a plugin (a plugin which needed
to access Rackspace Cloud Files) - https://github.com/rackspace/php-
opencloud. I used composer (as the README recommends), and the maximum
element in there came to something like 85 characters. This is without wp-
content/plugins/myslug... with the plugin in question, that came to 115
characters. I got 3 support requests from users who'd been hit by a
256-character limit within the next 3 days. This case won't be fixed by
this ticket - for that one, I had to move lots of the SDK around - I'm
just using this as an example of how the limits get hit without doing
anything extreme.
I reckon if I've managed to get hit by 256-character pathname limits in 3
independent ways, then it must be happening to others. I've lost plenty of
man-hours on it (most recently earlier this week).
--
Ticket URL: <https://core.trac.wordpress.org/ticket/26626#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list