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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
