This is an immediate release of Cuckoo Sandbox 1.1.1, an hotfix for a security vulnerability discovered by Robert Michel from G-Data. The vulnerability is an arbitrary file upload from the guest virtual machines to the host system, which could potentially translate in command or code execution. It affects all versions of Cuckoo Sandbox from 0.6.
The bug exists in the function read_next_message() of the class FileUpload in lib/cuckoo/core/resultserver.py. This function receives instructions from the guests on files (such as screenshots or dumped files) that needs to be stored in the current analysis folder.
buf = self.handler.read_newline().strip().replace("\\", "/")
log.debug("File upload request for {0}".format(buf))
if "../" in buf:
raise CuckooOperationalError("FileUpload failure, banned path.")
...
file_path = os.path.join(self.storagepath, buf.strip())
fd = open(file_path, "wb")
chunk = self.handler.read_any()
while chunk:
fd.write(chunk)
Due to an insufficient sanitizing of the buf variable, an attacker could craft an executable that, when analyzed by the sandbox, would instruct the Cuckoo daemon to create or overwrite any arbitrary file on the host system. Under some circumstances, this could lead to command or code execution on the host system, from within the virtual machine. The issue relies on some behavior from Python's os.path.join() function that we did not expect:
>>> import os
>>> sub = '/home/'
>>> os.path.join('base/', sub)
'/home/'
>>>
As you can see, if a sub-path to be concatenated through os.path.join() is actually an absolute path, it will overwrite any precedent parts. This is a behavior we were not aware of and it is the root cause of the vulnerability.
The simple hotfix for the moment consists in extending the validation of the path:
if "../" in buf or buf.startswith("/"):
raise CuckooOperationalError("FileUpload failure, banned path.")
We will however reconsider the design of this whole mechanism in the current development branch.
We invite everyone running a Cuckoo Sandbox installation to update to 1.1.1 immediately.
Thanks again to Robert Michel, who's credited for the discovery of this vulnerability and who responsibly disclosed it to us.