At the end of November I noticed a file-handling function in PHP that was going unnoticed by developers, perhaps because it seemed harmless. The function in question is unlink, which, for those who do not know, works to delete a file in the filesystem.
It is common to worry about file upload features, even those that read. Unfortunately, they forget the deletion.
This analysis was possible, because I was working with one more project of mine, the Tintin. That consists of static analysis of the code in order to find some security bug.
See the list at the end of the post.
When the unlink function is used together with a data input per parameter (be it GET, POST, REQUEST). A security breach may exist.
Unlink ($ _GET [‘filename’]);
If you send $ _GET [‘filename’] name of important files to your system, this can be fatal. As for example, in the case of WordPress with wp-config.php:
Depending on the use of the unlink you will have to walk backwards in the directories with ../, and possibly the file will be deleted.
And by default in wordpress, when accessing the system after this action, you can do a new installation and point to the database you want.
Bingo!! Attack success.
NOTE: The problem of the unlink is not only WordPress but of PHP in general. But now I am focus on WordPress.
There are over 270,000 active downloads with this issue. Despite this, I believe that only bit more of half of them will be accepted as security bug’s, that is 150,000 (which is not enough), the other part will not be considered as a security bug, because they are executed only with administrator and for having a validation against CSRF .
Despite the two defense mechanisms, is it still a flaw? For me, yes, I consider it a low level security bug or simply bug, for the simple fact of taking action on the system that was not its purpose, and may even restart every system.
All plugins are reported, some already solved.
Every problem has a lot of solutions I’m going to indicate a few:
Use of filters:
PHP / WordPress -> Remove the use of “../” to walk between folders. But do the correct way to avoid a bypass in the attack, delete by “..” and “/” parts.
PHP / WordPRess -> If you have a default folder specify I recommend use the basename method to extract only the filename and remove the full path of the folder.
I made a commit to the WordPress core to improve security for this failure by blocking default core folders and not letting core directory files be deleted. But I created a mechanism that frees directory by directory, in case you really need to delete something from the core. It’s still under review for approval, right here.
It was not accepted, but I will open another one again explaining some questions better. Because WordPress needs to have a method that saves the core folder.
Small response to “no”.
It is obvious that I will never be able to ban the use of the unlink, nor can I forbid them to make querys without using $ wpdb, I will never be able to prohibit default php methods, but WordPress has a responsibility to have a method with the minimum of security.
Exploits will be released when adjustments are made.
|Title||Level||Type||Data Discovery||Publish||Contact Vendor||Resolved||Possible Targets|
|Plugin Buddypress Xprofile Custom Fields Type 2.6.3 Arbitrary File Deletion - Unlink||high||
|Plugin Media Library Assistant 2.65 RCE - Unlink / Local File Download||medium_low||
|Plugin Woo Import Export 1.0 Arbitrary File Deletion - Unlink||medium_high||
|Plugin Woocommerce CSV importer 3.3.6 - Arbitrary File Deletion - Unlink||medium_high||
|Plugin WPBackItUp Backup 1.15.3 - RCE - Unlink||low||
|Plugin Google Drive for WordPress 2.2 - Arbitrary File Deletion - Unlik||high||
|Plugin Synchi 5.1 - Arbitrary File Deletion - Unlink||medium_high||