-
Notifications
You must be signed in to change notification settings - Fork 21.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
torch.jit.annotations.parse_type_line
is not safe (command injection) even it seems already deprecated.
#88868
Comments
Marking for triage review(and not assigning |
Yes, this seems not a very urgent bug, but we still need to pay attention to these dangerouse functions such as |
We should have a doc marking unsafe function and safe versions of the same. |
That's right, there was also a cve (https://github.com/tensorflow/tensorflow/blob/master/tensorflow/security/advisory/tfsa-2022-060.md) in tensorflow that used |
It seems reasonable, that valid type annotations should not have any funciton/method calls, so splitting it into |
Hi guys, is there any plan to release this patch to torch 1.12.x and 1.13.x? any ETAs? thanks! |
We don't currently have any plans to do continued releases for 1.12.x but given the security implications of this this patch will be included in the next patch release for 1.13.x |
Introduce `_eval_no_call` method, that evaluates statement only if it does not contain any calls(done by examining the bytecode), thus preventing command injection exploit Added simple unit test to check for that `torch.jit.annotations.get_signature` would not result in calling random code. Although, this code path exists for Python-2 compatibility, and perhaps should be simply removed. Fixes pytorch#88868 Pull Request resolved: pytorch#89189 Approved by: https://github.com/suo
Introduce `_eval_no_call` method, that evaluates statement only if it does not contain any calls(done by examining the bytecode), thus preventing command injection exploit Added simple unit test to check for that `torch.jit.annotations.get_signature` would not result in calling random code. Although, this code path exists for Python-2 compatibility, and perhaps should be simply removed. Fixes #88868 Pull Request resolved: #89189 Approved by: https://github.com/suo Co-authored-by: Nikita Shulga <nshulga@meta.com>
Can someone explain in more detail what the actual vulnerability is and how to determine whether a given code base actually uses the offending code? The Pytorch/jit docs (link) note that “Python 3 type hints can be used in place of Does this vulnerability apply only to compiled functions using Pytorch, or does it extend to things that could be injected into an inference request to trigger the privilege escalation issue? |
I believe the vulnerability is, if someone crafts a malicious Python file, and then you compile it TorchScript, it can trigger arbitrary code execution. That being said, I'm not really sure what your threat model is, since you probably already have problems if you're compiling arbitrary malicious Python code with TorchScript? |
That was my assessment as well, based on a cursory read of the issue and the docs I could find. It does seem confusing that the CVSS score lists the attack vector as "Network", attack complexity as "Low", and privileges required as "None" if this vulnerability requires compiling the malicious python code to TorchScript. The CVSS makes it seem like someone could trigger the vulnerability via (for example) a maliciously-crafted inference request (without any arbitrary code compilation) -- which would certainly be a critical security vulnerability. I'm interested in ruling that out if possible, especially while we wait for a patched version to be released... |
Definite not via user controlled tensor inputs. There is no vector for type annotations there |
I guess the problem here is that |
hello, is there an ETA on 1.13.1? |
@abustamante-coveo tentatively Dec 15th, see #89855 |
Introduce `_eval_no_call` method, that evaluates statement only if it does not contain any calls(done by examining the bytecode), thus preventing command injection exploit Added simple unit test to check for that `torch.jit.annotations.get_signature` would not result in calling random code. Although, this code path exists for Python-2 compatibility, and perhaps should be simply removed. Fixes pytorch#88868 Pull Request resolved: pytorch#89189 Approved by: https://github.com/suo
hello, Snyk still marks torch as having a critical vulnerability even after the 1.13.1 patch. Was this vulnerability supposed to be patched on that version? |
Looks like their vulnerability database is not updated after the fix. It shows that the fix is pushed but not published: |
🐛 Describe the bug
In
torch.jit.annotations
, it looks like there are some functions that are deprecated, but still retain code, which may lead to some backdoors, especially since some of these functions still use eval while implementing.But now I'm not sure if there are some features (jit decorator) in some version of pytorch are still using this function
parse_type_line
orget_signature
which callsparse_type_line
, if so, it can cause RCE, if not, maybe someone can also leave a backdoor by calling this function while writing code and share it to the people.Versions
master
cc @ezyang @gchanan @zou3519 @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
The text was updated successfully, but these errors were encountered: