file /wp-content/plugins/updraftplus/admin.php line 1843 function plupload_action
via the name parameter to set filename, and move file content into this file.
The server will do a basic verification of the file name, you can get a valid backup file name,just like backup_2017-11-29-1844_test_d6c634e49869-plugins.zip.
after the 39 lines, this file be delete
there are Race condition, when we view this pages before delete after write in. we can make php code execution.
@LoRexxar If somebody can log in as a WP administrator, then they donot need to carry out complicated "attacks" against upload race conditions that only they have access to. Instead, they can just doanyof10,000 other things to manipulate your filesystem, e.g.
Install a WP file manager pluginand manipulate the filesystem at will
Install their own malicious pluginor theme directly using the WP plugin uploader
Upload a malicious backupof their own creationandrestore it
Download an existing backup, edit it, upload it andrestore it
Use the in-built WordPress code or theme editor to edit existing parts of WordPress
For something to be an attack, it has to give a user powers that they did not already have. A procedure that allows them, through a very complicated work-around method, todo something that they could already dothrough many other mechanisms isnot an attack. Admins can already do the same thing in zillions of other ways. UpdraftPlus is a backup/restoreplugin! An evil admin can just create a malicious backup, andthenrestore it.... he doesn't need to do something really convoluted as an alternative.
@LoRexxar Whether I think that WordPress should be able towritetothe filesystem ornot, isnot a question formeinmy position. I am not part ofthe WordPress core team. If WordPress could notwritetothe filesystem, then a backup/restore plugin would be theoretically impossible. We can only deal with WP asitis. In WP's security model, WP can writetothe filesystem and this isnot considered a defect; and admins are all powerful (N.B. a "super admin"isthe all-powerful admin on a WP multisite install; but UD's code already handles that correctly too).
Note also that your attack cannot work for a further reason. The code cannot write directly into wp-content... the description just assumes you can write there and perform a directory traversal . But thefile location ofthefile during upload is PHP's temporary directory... andafterthat, it gets moved to a file ending in '.zip.tmp' in a directory that's protected with an .htaccess file, with directory traversal prevented by use of basename(). There's no mechanism for achieving that, orforrunning a .zip.tmp fileas a PHP file. It seems that you've not tried to actually carry out this 'attack' in practice?
For me, the important thing is just that you retract the report andthe CVE application. Once a CVE number gets granted, itthen appears in lots of automated security tools. We then have a problem of1 million active users who are going to be scared, andit will create a huge avalanche of support requests and negative publicity for us. So please can you retract itas soon as possible? Thank you!
So, what's your problem withthe authenticity ofthe vulnerability? You've asked why this isnot a vulnerability . I've already answered that; it's because a vulnerability is something that you did not already have access to do through other mechanisms, by design. A vulnerability cannot include something in which the highest-level user deliberately tries to hurt himself. Beyond these scopes, we are only talking about inconsequential opinions about coding style.
The following isnot a security hole in WordPress:
Log inas an admin Edit all site content inthe posts editor and replace itwiththewords"I HACKED YOUR SITE!!!" Do you understand why thatitisnot a security hole in WordPress's posts editor?
Or to give another example. WordPress core, by deliberate design, doesnot allow people atthe"author" level to inject JavaScript into a post. It does, however, allow them to inject itif they are an admin. That is because admins are all-powerful. They can already break the site by any method that they like.
So, at best, you are describing "a way for an admin to achieve something that he is already intentionally allowed to achieve 10,000 other ways (eg. restoring an evil backup)". That isnot what security researchers label as a vulnerability.
