This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients christian.heimes, docs@python, steve.dower, vstinner
Date 2021-03-08.20:26:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
In-reply-to
Content
Recently, the PEP 578 audit hooks was used to build a Capture The Flag (CTF) security challenge, AntCTF x D^3CTF: https://d3ctf.io/

Multiple issues have been reported to the Python Security Response Team (PSRT) from this challenge. It seems like there was a misunderstanding on the intent of the PEP 578.

Building a sandbox using audit hooks is *explicitly* excluded from the PEP 578 design:
https://www.python.org/dev/peps/pep-0578/#why-not-a-sandbox

See also the PEP 551 for more details.

The problem is that these two PEPs are not well summarized in the Python documentation, especially in the sys.addaudithook() documentation:
https://docs.python.org/dev/library/sys.html#sys.addaudithook

The documentation should better describe limitations of audit hooks, and may also point to these two PEPs for more information (PEP 578 is already mentioned).

The bare minimum should be to explicitly say that it should not be used to build a sandbox. 

By design, audit events is a whack a mole game. Rather than starting from a short "allow list", it is based on a "deny list", so it cannot be safe or complete by design. Every "forgotten" audit event can be "abused" to take the control on the application. And that's perfectly *fine*. It should just be documented.
History
Date User Action Args
2021-03-08 20:26:14vstinnersetrecipients: + vstinner, christian.heimes, docs@python, steve.dower
2021-03-08 20:26:14vstinnersetmessageid: <1615235174.36.0.713670774369.issue43438@roundup.psfhosted.org>
2021-03-08 20:26:14vstinnerlinkissue43438 messages
2021-03-08 20:26:13vstinnercreate