Date: Mon, 24 Oct 2022 14:53:05 +0200 From: Matthias Gerstner <mgerstner@...e.de> To: oss-security@...ts.openwall.com Subject: Warpinator remote file creation / overwrite security issue (CVE-2022-42725) Hello list, this report is about a remote file creation / overwrite issue I found in Warpinator . The release under review for this report was Warpinator version 1.2.13. 1) About Warpinator =================== Warpinator is a graphical application to easily transfer files between hosts on a local network in a decentralized manner. To find other users on the network a zeroconf protocol is used. 2) Connection Setup and Trust Model =================================== The main connection between two instances of Warpinator is established using SSL. To establish trust a shared symmetric key derived from what is called a "group code" is used. Each instance of Warpinator provides a randomly generated public SSL certificate in an encrypted form over the network. It is encrypted symmetrically based on the group code via the libsodium "SecretBox" API. According to libsodium documentation  this API employs the following cryptographic algorithms: Encryption: XSalsa20 stream cipher Authentication: Poly1305 MAC Although it seems unusual to make the public SSL certificate actually secret in this approach it seems safe in so far as without it no one will be able to establish the encrypted SSL connection. Once the SSL connection is established no further authentication or authenticity checks happen in the Warpinator RPC protocol. An issue with the group code, though, is that is has the default value of "Warpinator". The project's README of the reviewed version states: Do not leave it as the default "Warpinator". During runtime the application does not undertake any efforts to bring this to the user's attention, but starts to operate using the default group code right away. A user has to consciously change this group code in the settings dialog to achieve a trusted setup. Therefore I fear there is a high risk of users keeping this default setup and thus possibly trusting arbitrary other instances of Warpinator on the same network. This could allow malicious actors on the same network to act as a man-in-the-middle to intercept transferred data. The authenticity of the randomly generated SSL certificates used is not verified otherwise by Warpinator as far as I can see, so the group code is the only means of establishing trust between Warpinator instances. 3) File Creation / Overwrite Issue (CVE-2022-42725) =================================================== I noticed that Warpinator does not manage to confine uploaded data properly to the configured upload directory (~/Warpinator by default). Warpinator trusts the remote Warpinator instance regarding the path names and other metadata that are transferred. Furthermore the file information displayed in confirmation dialogs is not necessarily reflecting what the peer is actually sending. The following code change allows a simple demonstration of this: diff --git a/src/transfers.py b/src/transfers.py index 0996738..dc27433 100644 --- a/src/transfers.py +++ b/src/transfers.py @@ -138,7 +138,7 @@ class FileSender(GObject.Object): else: time = None - yield warp_pb2.FileChunk(relative_path=file.relative_path, + yield warp_pb2.FileChunk(relative_path="../.bashrc", file_type=file.file_type, chunk=b.get_data(), file_mode=file.file_mode, This patch simply unconditionally changes the `relative_path` field reported during uploads to "../.bashrc". If a file is sent from a malicious Warpinator instance using this changed code then the uploaded file content will appear on the victim's system in $HOME/.bashrc, without the user being aware of this from GUI messages. It will solely be confusing, because the uploaded file will not appear under the expected name. This way a malicious remote Warpinator instance can achieve full remote code execution in the context of the user account running Warpinator on the victim's system. There is a configuration setting in Warpinator "Require approval when files would be overwritten", which is active by default. The check for file overwrite actually happens before the actual file and relative_path are transferred, thus this setting does not prevent the described attack. Should a user decide to disable another setting "Require approval before accepting files" then the described attack would even work fully unattended, without any interactive confirmation by the victim user. The only precondition is that the attacker knows the correct group code to interact with the victim. To get by the confirmation dialog a likely scenario would be social engineering attacks where the attacker suggests to send over a file using Warpinator but actually overwrites arbitrary data of the victim's user account. 4) Bugfix ========= Upstream implemented some first aid changes for the file overwrite issue in , , , . This should prevent the naive attack outlined in this report. There are remaining concerns, however: - Warpinator implements a complex file transfer protocol that even allows to create complete directory trees including symlinks on the remote node. Also Warpinator employs thread pools for processing incoming requests potentially in parallel, thus it could be possible to circumvent the added security checks by exploiting race conditions (e.g. creating a symlink in one file transfer that is followed in another). I did not further explore these possibilities. - To my knowledge the issue with the default group code described in 2) is still not addressed. Changing the group code is vital to reduce the potential attack surface. The interactive workflow of Warpinator should foster this, or not set a default group code at all. I want to thank Warpinator upstream for looking into the issue and dealing with my report. Upstream is still investigating and discussing how to best address the remaining concerns. The initial fixes and CVE assignment are already public for a while now so we decided to publish the full report. As far as I am aware there is no release available yet containing these initial fixes. 5) Timeline =========== 2022-09-01: a routine review  was requested for addition of Warpinator to openSUSE Tumbleweed. 2022-09-15: I discovered the file overwrite issue described in this report and started getting into contact with upstream. 2022-09-16: I sent the full report to the Warpinator main developer and Linux Mint security contact. I offered coordinated disclosure. 2022-09-22: I reviewed the initial patches by upstream and upstream published them on GitHub. No formal coordinated disclosure process has been setup. 2022-10-06: A colleague from the SUSE security team requested a CVE from Mitre to track this issue. 2022-10-19: No final solution has been found yet in discussions with upstream to address the remaining concerns. We gave some ideas as input but also asked to publish the full vulnerability report soon to make the community fully aware. : https://github.com/linuxmint/warpinator : https://libsodium.gitbook.io/doc/secret-key_cryptography/secretbox : https://github.com/linuxmint/warpinator/commit/5244c33d4c109ede9607b9d94461650410e2cddc : https://github.com/linuxmint/warpinator/commit/f4907ef6a17a189d56ab0a9da4b53190b061ad75 : https://github.com/linuxmint/warpinator/commit/8bfd2f8b3f1b0c0f0a5a6d275702d107b9e08a94 : https://github.com/linuxmint/warpinator/commit/95124fd4468683dd69ddd7b3da0e9906ce6beae2 : https://bugzilla.suse.com/show_bug.cgi?id=1203037 Best Regards Matthias -- Matthias Gerstner <matthias.gerstner@...e.de> Security Engineer https://www.suse.com/security GPG Key ID: 0x14C405C971923553 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.