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

[Steve Dower]

On 28Aug2017 1834, Gregory P. Smith wrote:
> 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).

Repeating the three main goals listed by the PEP:
* preventing malicious use is valuable
* detecting malicious use is important
* detecting attempts to bypass detection is critical

This case falls under the last one. Yes, it is possible to patch the 
interpreter (at least in systems that don't block that - Windows 
certainly can prevent this at the kernel level), but in order to do so 
you should trigger at least one very unusual event (e.g. any of the 
ctypes ones).

Compared to the current state, where someone can patch your interpreter 
without you ever being able to tell, it counts as a victory.

And yeah, if you have alternative interpreters out there that are not 
auditing, you're in just as much trouble. There are certainly sysadmins 
who do a good job of controlling this though - these changes enable 
*those* sysadmins to do a better job, it doesn't help the ones who don't 
invest in it.

> 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.

You can audit all code before it executes and prevent it. Whether you 
use a local malware scanner or some sort of signature scan of log files 
doesn't matter, the change *enables* you to detect this behaviour. Right 
now it is impossible.

> This audit layer seems like a defense against existing exploit kits
> rather than future ones.

As a *defense*, yes, though if you use a safelist of your own code 
rather than a blocklist of malicious code, you can defend against all 
unexpected code. (For example, you could have a signed catalog of code 
on the machine that is used to verify all sources that are executed. 
Again - these features are for sysadmins who invest in this, it isn't 
free security for lazy ones.)

> Is that still useful from a defense in depth
> point of view?

Detection is very useful for defense in depth. The new direction of 
malware scanners is heading towards behavioural detection (away from 
signature-based detection) because it's more future proof to detect 
unexpected actions than unexpected code.

(If you think any of these explanations deserve to be in the PEP text 
itself, please let me know so I can add it in. Or if you don't like 
them, let me know that too and I'll try again!)

Cheers,
Steve