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

[Gregory P. Smith]

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()
> time_to_do_nothing = time() - t
> audit = sys.audit
> t = time()
> audit()
> time_to_do_audit = time() - t
> if time_to_do_audit <= time_to_do_nothing:
>     do_something_bad()
>
>
> 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>