Uproot potential security threats when working on server side

[DraTeots]

At EIC, we are considering running Uproot on a server where users can provide an URL, and the server executes uproot.open('user-provided-input') and then process TTree-s. We now are concerned about potential security implications of this setup and would like to discuss if there are any risks we should be aware of. Maybe developers thought of it already, maybe there are examples and best practices?

To be more specific, here is our scenario:

0. Scenario:

   • Users enter a file name or URL in a browser form.
   • The server uses uproot.open to open the file, reads a TTree, and returns JSON data.
   • EIC uses XRootD heavily, so we basically chose uproot on server-side because of xrootd support (otherwise jsroot could be used on client-side)

1. Path Traversal Attacks - Imagine users try to access files like /etc/passwd or other sensitive system files. It seems uproot should fail to find a TTree in such files and raise an error. But we want to ensure that this does not expose any vulnerabilities. (There definitely should be validation and sanitization of local files access, but imagine it is dodged or failed, would uproot part considered safe and we are good?)

2. Accessing Remote Files via xrootd and HTTP(S):

   • The primary purpose of our server is to access files located on xrootd servers, as EIC heavily uses xrootd. Therefore, we need to allow root://... links, and possibly http:// and https:// URLs.
   • Are there any security implications with allowing these protocols in uproot? For example, could this be exploited for Server-Side Request Forgery (SSRF) attacks?

3. Execution of Malicious Code:

   • Does Uproot use any methods like eval or dynamic code execution that could result in malicious code being executed on the server when a specially crafted .root file is processed?
   • Are there known vulnerabilities related to parsing untrusted ROOT files that we should be aware of?

4. Denial of Service (DoS): - probably not uproot part, but one can imagine users providing URLs to extremely large files or files that could cause excessive resource consumption during parsing. Maybe there could be thoughts and prayers on uproot side?

5 Command Injection: - Does any part of the file handling involve shell commands (e.g., downloading files)? - probably no, but just asking...

Additional questions:

• Are there best practices or recommended security measures when using Uproot in such a server-side context?
• Does the Uproot team have any guidelines or tools to help mitigate these potential risks?
• Maybe there are some good open source examples where security measures could be examined?

We appreciate any insights or recommendations you can provide!

P.S. I apologize if the information is available, I couldn't find in issues, discussions and documentation.

[jpivarski]

We don't have a statement on security, but you can rely on Uproot being a naive library when it comes to security. It doesn't attempt to protect sensitive files from

uproot.recreate("/etc/passwd")   # effectively deletes /etc/passwd

Thus, you'd want to design as much caution around Uproot as you would around a library like h5py or Python's os module.

Despite the malicious example above, which can destroy files, it's hard to see how sensitive information could be revealed with uproot.open (unless you have sensitive ROOT data). If the first 4 bytes of the file are not b'root', then Uproot stops reading immediately, and it would be very difficult for a file to accidentally conform to ROOT format, far enough to get to something sensitive.

There are various methods to pass security credentials to the XRootD and HTTPS handling, and I don't know how those would fare in a secured context. Will the users need to pass security credentials to the server, for the server to apply? Or would the server know the security credentials of the file-server that it's talking to? (Or does none of that matter, once you're in-network?)

Server-Side Request Forgery (SSRF) attacks

I'm not familiar with the term.

Uproot does use exec and eval.

1. When Uproot encounters unfamiliar C++ classes, it uses ROOT's TStreamerInfo¹ to learn how to deserialize them and it generates a Python class definition as a string. This string is then turned into a class object by running it through exec. The contents of this class are strictly dictated by TStreamerInfo. The only way that arbitrary code (e.g. sys.exit(0)) could get inserted into this class definition is through a bug, if one of the variables used to generate parts of the code is not unquoted programatically. I don't think there are any such bugs, since it was our policy to use repr and sometimes json to quote and unquote code snippets going into the class definition. It shouldn't be hard to add a configuration option that tells Uproot to never read or make use of TStreamerInfo: then it will be limited to files for which it has predefined Models, which includes basic TTrees and histograms.
2. The expressions and cut arguments of uproot.TTree.arrays, uproot.TTree.iterate, uproot.iterate, and uproot.concatenate are arbitrary Python expressions that get evaluated. These expressions are evaluated in a Python namespace in which only TBranch names (variables) and a limited suite of functions are available, and even if some of these functions had attributes that might let users break out, the . syntax is interpreted as part of a TBranch name, so the expression can't follow subscripts. However, if you're allowing users to name arbitrary TBranches in the file to fetch, don't pass that list to the expressions (or cut) arguments; use filter_name instead. filter_name can take wildcards (maybe you want that), but it never evaluates expressions.

Denial of Service (DoS): - probably not uproot part, but one can imagine users providing URLs to extremely large files or files that could cause excessive resource consumption during parsing. Maybe there could be thoughts and prayers on uproot side?

Uproot doesn't give up until the file is read: that's part of its naivety. (If it wasn't naive, then a timeout on large files would be a disastrous surprise for other users.) Often XRootD does this itself, though: many of the reported errors in Uproot are instances where the remote XRootD server gives up or gets disconnected or something. It manifests as an exception in Uproot.

Uproot never uses external commands (no subprocess.run or os.system).

As for general guidelines, this GitHub Discussion is the first conversation I've had about Uproot in server-side contexts. Well... ServiceX has an Uproot-Transformer that runs on a server; maybe some of the same issues apply there (but we've never talked about security). I think that ServiceX runs Uproot in some kind of sandbox, maybe a Docker container that has no access beyond its read-only function, which is easy to interrupt and reboot?

Footnotes

1. In ROOT itself, there's a way to inject arbitrary C++ code with a malicious file. The TStreamerInfo mechanism has a feature that allows "streamer rules" to be executed to convert classes of version X into classes of version Y, and these are bare C++ strings in the ROOT file that Cling compiles and runs. Uproot is incapable of executing these rules because it doesn't have access to a C++ compiler. However, it would be difficult to construct such a file—it would depend strongly on the version of ROOT that is opening the file. ↩