Skip to content

Commit

Permalink
PEP 768: Expand the security considerations section (#4173)
Browse files Browse the repository at this point in the history
  • Loading branch information
pablogsal authored Dec 16, 2024
1 parent cbf8efb commit a79f847
Showing 1 changed file with 58 additions and 1 deletion.
59 changes: 58 additions & 1 deletion peps/pep-0768.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
=======================
Expand All @@ -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
Expand Down Expand Up @@ -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
=================

Expand Down

0 comments on commit a79f847

Please sign in to comment.