`torch.jit.annotations.parse_type_line` is not safe (command injection) even it seems already deprecated.

[Lyutoon]

🐛 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 or get_signature which calls parse_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.

import torch

torch.jit.annotations.parse_type_line('# type: __import__("os").system("ls") -> 234', None, 1)

Versions

master

cc @ezyang @gchanan @zou3519 @EikanWang @jgong5 @wenzhe-nrv @sanchitintel

[malfet]

Marking for triage review(and not assigning oncall: jit yet otherwise it will disappear to the void) to discuss what to do with those kinds of security issues, which, in my opinion, is pretty minor: if one have an access to local Python runtime they can do anything they want.

[Lyutoon]

Marking for triage review(and not assigning oncall: jit yet otherwise it will disappear to the void) to discuss what to do with those kinds of security issues, which is in my opinion is pretty minor: if one have an access to local Python runtime they can do anything they want.

Yes, this seems not a very urgent bug, but we still need to pay attention to these dangerouse functions such as eval. And in CVE-2022-0845, this bug is also caused by using eval to parse the args so it leads to code injection, and it seems also must have an access to local python. To be honest, I don't know how people think about these kind of problems, but we need to pay more attention :p. So we need a discuss about it whether it can be considered as a big security problem.

[malfet]

We should have a doc marking unsafe function and safe versions of the same.
And also, probably should not use eval, if possible.

[Lyutoon]

We should have a doc marking unsafe function and safe versions of the same. And also, probably should not use eval, if possible.

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 eval in saved_model_cli and caused code injection. Also I've found that PaddlePaddle has also eval problems (https://github.com/PaddlePaddle/Paddle/blob/develop/security/advisory/pdsa-2022-002.md). But sometimes, if we do not use eval, the code will become much more complex. Maybe developers can just add a critical check about the parameters of the function to avoid this problem easily (if possible).

[malfet]

It seems reasonable, that valid type annotations should not have any funciton/method calls, so splitting it into compile (which is safe)->error on function calls->eval would secure the deprecated codebase without overcomplicating deprecated code too much