[Python-Dev] PEP 551: Security transparency in the Python runtime

[Steve Dower]

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