On Montag, 15. August 2016 10:02:55 CEST moparisthebest wrote: > Hello, > > I find it extremely hard to call this a wget vulnerability when SO many > other things are wrong with that 'vulnerable code' implementation it > isn't even funny: > > 1. The image_importer.php script takes a single argument, why would it > download with the recursive switch turned on? Isn't that clearly a bug > in the php script? Has a php script like this that downloads all files > from a website of a particular extension ever been observed in the wild? > > 2. A *well* configured server would have a whitelist of .php files it > will execute, making it immune to this. A *decently* configured server > would always at a minimum make sure they don't execute code in > directories with user provided uploads in them. So it's additionally a > bug in the server configuration. (incidentally every php package I've > downloaded has at minimum a .htaccess in upload directories to prevent > this kind of thing with apache) > > It seems to me like there has always been plenty of ways to shoot > yourself in the foot with PHP, and this is just another iteration on a > theme.
Hi, this is absolutely true and your points were the first things that came to my mind when reading the original post. But there is also non-obvious wget behavior in creating those (temp) files in the filesystem. And there is also a long history of attack vectors introduced by temp files as well. Today the maintainers discussed a few possible fixes, all with pros and cons. I would like to list them here, in case someone likes to comment: 1. Rewrite code to keep temp files in memory. Too complex, needs a redesign of wget. And has been done for wget2... 2. Add a harmless extension to the file names. Possible name collision with wanted files. Possible name length issues, have to be worked around. 3. Using file mode 0 (no flags at all). Short vulnerability when changing modes to write/read the data. 4. Using O_TMPFILE for open(). Just for Linux, not for every filesystem available. 5. Using mkostemp(). Possible name collision with wanted files (which would be unexpectedly named as *.1 in case of a collision). At least the chance for a collision seems very low. Any thoughts or other ideas ? Regards, Tim
signature.asc
Description: This is a digitally signed message part.
