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

Gregory P. Smith greg at krypto.org
Mon Aug 28 21:34:29 EDT 2017

My gut feeling says that there are N interpreters available on just about every bloated system image out there. Multiple pythons are often among them, other we do not control will also continue to exist. I expect a small initial payload can be created that when executed will binary patch the interpreter's memory to disable all auditing, potentially in a manner that cannot be audited itself (a challenge guaranteed to be accepted).

If the goal is to audit attacks and the above becomes the standard attack payload boilerplate before existing "use python to pull down 'fun' stuff to execute". It seems to negate the usefulness.

This audit layer seems like a defense against existing exploit kits rather than future ones. Is that still useful from a defense in depth point of view?

-gps

On Mon, Aug 28, 2017 at 6:24 PM Steven D'Aprano <steve at pearwood.info> 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?)

[...] > 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. [...] > 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: from time import time f = lambda: None t = time() f() timetodonothing = time() - t audit = sys.audit t = time() audit() timetodoaudit = time() - t if timetodoaudit <= timetodonothing: dosomethingbad() 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.

-- Steve

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170829/08be0133/attachment.html>

More information about the Python-Dev mailing list