Bugzilla – Bug 1207480
VUL-0: CVE-2023-29380: warpinator: file upload can lead to arbitrary file deletion
Last modified: 2023-04-28 21:45:04 UTC
+++ This bug was initially created as a clone of Bug #1203463 Since I've been ask to verify the fix for bug 1203463 I stumbled over another (or newly introduced) issue in the Warpinator upload logic. While the actual file creation logic is now somewhat more robust, there is a newly introduced "top_dir_basenames" list that is passed from the peer and this input is not verified whatsoever. The problematic usage is in FileReceiver.__init__(): ``` for name in op.top_dir_basenames: try: path = os.path.join(self.save_path, name) if os.path.isdir(path): # file not found is ok shutil.rmtree(path) else: os.remove(path) except FileNotFoundError: pass except Exception as e: logging.warning("Problem removing existing files. Transfer may not succeed: %s" % e) ``` So the constructor tries to make sure the the new upload path does not exist. However the path is not tested for sanity. The peer can specify whatever it wants here. Since this is also recursively deleting directories it can be used to delete the complete home directory of the victim simply by specifying "../" as top_dir_basename (assuming the default upload directory of ~/Warpinator). Thus this represents a veritable remote DoS attack vector (could be considered kind of "authenticated" remote DoS, since all parties need to share the same group code, but it is not really a high bar to climb with respect to some social engineering). I will approach upstream tomorrow with this new find.
I have sent a longer report to upstream, so let's see how we continue with this when they reply.
Internal CRD: 2023-04-25 preliminary
I received a CVE from Mitre for this issue as shown in the bug summary. Upstream has been pretty busy coming up with some major improvements to prevent such issues in the future. Warpinator will use either bubblewrap (namespace jail) or landlock (kernel level self-confinement for applications). I still don't know of a formal publication date since upstream is still testing the changes. It shouldn't take too long though.
Today the maximum embargo period of 90 days has been reached. Upstream agrees to publish everything tomorrow. A new major release version 1.6.0 has been created that contains all the additional hardening.
Publishing the bug to silence our monitoring that spits out warnings because of the ended embargo. I will publish a formal report today on the oss-security mailing list. @badshah400: When you package the new major version 1.6.0 then Warpinator can finally enter Factory.
The final report is now public on oss-security: https://seclists.org/oss-sec/2023/q2/105 It looks like the vulnerability wasn't actually introduced by the CVE fix, but already existed longer.
(In reply to Matthias Gerstner from comment #5) > Publishing the bug to silence our monitoring that spits out warnings because > of the ended embargo. > > I will publish a formal report today on the oss-security mailing list. > > @badshah400: When you package the new major version 1.6.0 then Warpinator can > finally enter Factory. Thanks Matthias for your amazing work. I have now sr'ed version 1.6.1 to the devel project.
Happy to help. If you are still blocked on anything (rpmlint errors?) then please tell me and I will whitelist it. Otherwise you can close the bug as fixed.
(In reply to Matthias Gerstner from comment #8) > Happy to help. If you are still blocked on anything (rpmlint errors?) then > please tell me and I will whitelist it. Otherwise you can close the bug as > fixed. Nope, all good, thanks.