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:
|
||||
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
|
||||
=======================
|
||||
|
@ -306,10 +330,14 @@ Security Implications
|
|||
=====================
|
||||
|
||||
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
|
||||
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
|
||||
against attackers gaining arbitrary memory write access. Although the PEP
|
||||
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
|
||||
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
|
||||
=================
|
||||
|
||||
|
|
Loading…
Reference in New Issue