PEP 768: Expand the security considerations section (#4173)
This commit is contained in:
parent
cbf8efbc53
commit
a79f847f4c
|
@ -294,6 +294,30 @@ An example usage of the API would look like:
|
||||||
except Exception as e:
|
except Exception as e:
|
||||||
print(f"Failed to execute code: {e}")
|
print(f"Failed to execute code: {e}")
|
||||||
|
|
||||||
|
Configuration API
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
To allow redistributors, system administrators, or users to disable this
|
||||||
|
mechanism, several methods will be provided to control the behavior of the
|
||||||
|
interpreter:
|
||||||
|
|
||||||
|
A new ``PYTHON_DISABLE_REMOTE_DEBUG`` environment variable will
|
||||||
|
be provided to control the behaviour at runtime. If set to any value (including an empty string), the
|
||||||
|
interpreter will ignore any attempts to attach a debugger using this mechanism.
|
||||||
|
|
||||||
|
This environment variable will be added together with a new ``-X disable-remote-debug``
|
||||||
|
flag to the Python interpreter to allow users to disable this feature at runtime.
|
||||||
|
|
||||||
|
Additionally a new ``--without-remote-debug`` flag will be added to the
|
||||||
|
``configure`` script to allow redistributors to build Python without support for
|
||||||
|
remote debugging if they so desire.
|
||||||
|
|
||||||
|
A new flag indicating the status of remote debugging will be made available via
|
||||||
|
the debug offsets so tools can query if a remote process has disabled the
|
||||||
|
feature. This way, tools can offer a useful error message explaining why they
|
||||||
|
won't work, instead of believing that they have attached and then never having
|
||||||
|
their script run.
|
||||||
|
|
||||||
|
|
||||||
Backwards Compatibility
|
Backwards Compatibility
|
||||||
=======================
|
=======================
|
||||||
|
@ -306,10 +330,14 @@ Security Implications
|
||||||
=====================
|
=====================
|
||||||
|
|
||||||
This interface does not introduce new security concerns as it is only usable by
|
This interface does not introduce new security concerns as it is only usable by
|
||||||
processes that can already write to arbitrary memory within your process and
|
processes that can already write to arbitrary memory within a given process and
|
||||||
execute arbitrary code on the machine (in order to create the file containing
|
execute arbitrary code on the machine (in order to create the file containing
|
||||||
the Python code to be executed).
|
the Python code to be executed).
|
||||||
|
|
||||||
|
Furthermore, the execution of the code is gated by the interpreter's
|
||||||
|
audit hooks, which can be used to monitor or prevent the execution of the code
|
||||||
|
in sensitive environments.
|
||||||
|
|
||||||
Existing operating system security mechanisms are effective for guarding
|
Existing operating system security mechanisms are effective for guarding
|
||||||
against attackers gaining arbitrary memory write access. Although the PEP
|
against attackers gaining arbitrary memory write access. Although the PEP
|
||||||
doesn't specify how memory should be written to the target process, in practice
|
doesn't specify how memory should be written to the target process, in practice
|
||||||
|
@ -368,6 +396,35 @@ proposed interface.
|
||||||
By maintaining compatibility with existing security frameworks, this design
|
By maintaining compatibility with existing security frameworks, this design
|
||||||
ensures that adopting the new interface requires no changes to established.
|
ensures that adopting the new interface requires no changes to established.
|
||||||
|
|
||||||
|
Security scenarios
|
||||||
|
------------------
|
||||||
|
|
||||||
|
* For an external attacker, the ability to write to arbitrary memory in a
|
||||||
|
process is already a severe security issue. This interface does not introduce
|
||||||
|
any new attack surface, as the attacker would already have the ability to
|
||||||
|
execute arbitrary code in the process. This interface behaves in exactly
|
||||||
|
the same way as existing debuggers, and does not introduce any new additional
|
||||||
|
security risks.
|
||||||
|
* For an attacker who has gained arbitrary memory write access to a process but
|
||||||
|
not arbitrary code execution, this interface does not allow them to escalate.
|
||||||
|
The ability to calculate and write to specific memory locations is required,
|
||||||
|
which is not available without compromising other machine resources that
|
||||||
|
are external to the Python process.
|
||||||
|
|
||||||
|
Additionally, the fact that the code to be executed is gated by the interpreter's
|
||||||
|
audit hooks means that the execution of the code can be monitored and controlled
|
||||||
|
by system administrators. This means that even if the attacker has compromised the
|
||||||
|
application **and the filesystem**, leveraging this interface for malicious
|
||||||
|
purposes provides a very risky proposition for an attacker, as they risk
|
||||||
|
exposing their actions to system administrators that could not only detect the
|
||||||
|
attack but also take action to prevent it.
|
||||||
|
|
||||||
|
Finally, is important to note that if an attacker has arbitrary memory write
|
||||||
|
access to a process and has compromised the filesystem, they can already
|
||||||
|
escalate to arbitrary code execution using other existing mechanisms, so this
|
||||||
|
interface does not introduce any new risks in this scenario.
|
||||||
|
|
||||||
|
|
||||||
How to Teach This
|
How to Teach This
|
||||||
=================
|
=================
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue