GHSA-43c9-gw4x-pcx6 Authenticated arbitrary file deletion in YesWiki

• Packagist yeswiki/yeswiki: < 4.5.0 → fixed in 4.5.0

Authenticated arbitrary file deletion in YesWiki fmRestore(); $this->fmShow(true, $isAction); break; case 'erase': $this->fmErase(); $this->fmShow(true, $isAction); break; case 'del': $this->fmDelete(); $this->fmShow(false, $isAction); break; case 'trash': $this->fmShow(true, $isAction); break; case 'emptytrash': $this->fmEmptyTrash(); //pas de break car apres un emptytrash => retour au gestionnaire // no break default: $this->fmShow(false, $isAction); } } ``` The fmErase() function doesn't sanitize or verify the path that has been provided by the user in any way. Thus allowing a malicious user to specify any arbitrary file on the filesystem and having it deleted through the use of `unlink()` (as long as the user that runs the process has permission to delete it). ```php public function fmErase() { $path = $this->GetUploadPath(); $filename = $path . '/' . ($_GET['file'] ? $_GET['file'] : ''); if (file_exists($filename)) { unlink($filename); } } ``` In addition to this deletion accross all the filesystem through `fmErase()`, it is also possible to delete any file attached to an existing wiki page, for instance, if user A creates a page and attaches images/documents to it, they always get uploaded to the files/ directory. If user B (malicious), knows the path of the files he can also arbitrarly delete them. (fmDelete() is also impacted by this case) PoC 1. Environnement setup > The following actions have been performed as a privileged user First, let's create one user (in addition to the WikiAdmin user): Restrict the edition of 'PagePrincipale' wiki page to administrators only: 2. Upload of a file on a resource not owned by our user > The following actions have been performed as a privileged user Second, let's upload a media to this `PagePrincipale` wiki page: Then view it in the page's filemanager: We can confirm that our file has been uploaded to the `files/` directory by directly looking at the `yeswiki` container: 3. Arbitrary deletion (in files/) > The following actions have been performed using an unprivileged user Now, get the full path/name of the media in the files directory by opening it in a new tab: Afterwards, we need an instance of filemanager to be accessible to our user so we need to create a page that we own, here is used the agenda and the creation of a new event: Call the `erase` method on the PagePrincipale's uploaded media: The media is now deleted from PagePrincipale (the button is shown when the attached media doesn't exist, it's an intended behaviour): It has also disappeared from the `files/` directory: This behaviour can be applied to any file under the `files/` directory. 4. Arbitrary deletion (in /tmp/) > The following actions have been performed using a privileged access Finally, using the same user as the process running the app, we create a file under the `/tmp` directory: > The following actions have been performed using an unprivileged user We can once again call the `erase` method using a relative path: The file isn't here anymore: Impact This vulnerability allows any authenticated user to arbitrarly remove content from the Wiki resulting in partial loss of data and defacement/deteroriation of the website. In the context of a container installation of YesWiki without any modification, the 'yeswiki' files (for example .php) are not owned by the same user (root) as the one running the FPM process (www-data). However in a standard installation, www-data may also be the owner of the PHP files, allowing a malicious user to completely cut the access to the wiki by deleting all important PHP files (like index.php or core files of YesWiki). Suggestion of possible corrective measures • Restrict the possible paths of `fmErase()` to the `upload_path` directory. • Restrict the use of `fmErase()` to trashed files only. ```php public function fmErase() { $path = $this->GetUploadPath(); $filename = $this->GetUploadPath() . '/' . basename(realpath(($_GET['file'] ? $_GET['file'] : ''))); //Sanitize file path if (file_exists($filename) && preg_match('/trash\d{14}$/', $filename)) { //Make sure that the filename ends with trash and a date unlink($filename); } } ``` • Make sure that any request to `fmErase()` or `fmDelete()` originates from the owner of the resource to which the attachment is linked (asks a bit more than a few lines of code).