This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author zach.ware
Recipients Alexander Riccio, brett.cannon, paul.moore, steve.dower, tim.golden, zach.ware
Date 2016-06-30.16:47:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1467305242.74.0.119596655712.issue26137@psf.upfronthosting.co.za>
In-reply-to
Content
> But in that case, why hook into exec? The malware author can execute 
> arbitrary Python so doesn't *need* exec.

As I understand it, the malware is distributed in encrypted form (probably encrypted differently each time it propagates) so as to be given a green-light by anti-malware software, then decrypted and run via exec so that the bad code is never actually on disk, and thus never scanned.  Yes, the attacker can run arbitrary Python code, but if he just distributed the code in plain text, it could be detected and blocked.  The unpacking code is simple and generic enough that it can't be blocked.


As far as actually enabling AMSI, I'm +0.  I don't understand it well enough to be +1, and I share Paul's concerns about startup overhead.  I'm also unsure that AMSI actually affords any protection: what's to stop the attacker from distributing their own interpreter that just doesn't use AMSI?
History
Date User Action Args
2016-06-30 16:47:22zach.waresetrecipients: + zach.ware, brett.cannon, paul.moore, tim.golden, steve.dower, Alexander Riccio
2016-06-30 16:47:22zach.waresetmessageid: <1467305242.74.0.119596655712.issue26137@psf.upfronthosting.co.za>
2016-06-30 16:47:22zach.warelinkissue26137 messages
2016-06-30 16:47:22zach.warecreate