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