[Python-Dev] PEP 551: Security transparency in the Python runtime (original) (raw)

Steve Dower steve.dower at python.org
Mon Aug 28 22:23:11 EDT 2017

On 28Aug2017 1815, Steven D'Aprano wrote:

Very nicely written. A few comments below.

On Mon, Aug 28, 2017 at 04:55:19PM -0700, Steve Dower wrote: [...] This PEP describes additions to the Python API and specific behaviors for the CPython implementation that make actions taken by the Python runtime visible to security and auditing tools. The goals in order of increasing importance [...] Check your line lengths, I think they may be too long? (Or maybe my mail client is set too short?)

Yeah, not sure what's happened here. Are PEPs supposed to be 80? Or 72?

[...]

To summarize, defenders have a need to audit specific uses of Python in order to detect abnormal or malicious usage. Currently, the Python runtime does not provide any ability to do this, which (anecdotally) has led to organizations switching to other languages. It would help if the PEP addressed the state of the art in other languages.

It briefly mentions that PowerShell has integrated similar functionality (generally more invasive, but it's not meant as a full application language).

As far as I know, no other languages have done anything at this level - OS-level scripting (WSH, AppleScript) rely on OS-level auditing and don't try to do it within the language. This makes sense from the point of view of "my system made a network connection to x.y.z.w", but doesn't provide the correlating information necessary to see "this Python code downloaded from x.com made a network connection to ...".

[...]

For example, sys.addaudithook() and sys.audit() should exist but may do nothing. This allows code to make calls to sys.audit() without having to test for existence, but it should not assume that its call will have any effect. (Including existence tests in security-critical code allows another vector to bypass auditing, so it is preferable that the function always exist.) That suggests a timing attack to infer the existence of auditing. A naive attempt: [...] This is probably too naive to work in real code, but the point is that the attacker may be able to exploit timing differences in sys.audit and related functions to infer whether or not auditing is enabled.

I mention later that timing attacks are possible to determine whether events are being audited. I'm not convinced that provides any usable information though - by the time you can test that you are being tracked, you've (a) already got arbitrary code executing, and (b) have already been caught :) (or at least triggered an event somewhere... may not have flagged any alerts yet, but there's a record)

Cheers, Steve

More information about the Python-Dev mailing list