On Sat, Jun 27, 2015 at 6:09 AM, Randall Smith <rand...@tnr.cc> wrote: > Give me one plausible scenario where an attacker can cause malware to hit > the disk after bytearray.translate with a 256 byte translation table and > I'll be thankful to you.
The entire 256-byte translation table is significant ONLY if you need all 256 possible bytes. Suppose I want to generate the following byte sequence: "\xCD\x19" (Okay, this is a slightly oversimplified example, as this attack doesn't work on a modern Windows. But back in the days of DOS, this program would reboot your computer.) How many truly different translation tables are there if I'm trying to produce this? Just 256*255, or 65280. If I send random two-byte files, there is one chance in that of my "malware" successfully landing. Once I've sent about 45,000 of those files, I have a fifty-fifty chance of having hit it. Send twice as many, I have a 75% chance of success, etc. Malware can be crafted to fit within certain restrictions. I saw a proof-of-concept and analysis document detailing a particular remote code execution/privilege escalation attack that involved stuffing "text" into an entry field and then inducing the program to read that into its stack, finally triggering it by some sort of buffer overflow, I think. The text had to be no more than X bytes long (because that's all the entry field was set to accept - it'd truncate after that), and had to not contain any NUL bytes, and there might have been other restrictions too. Sure, it makes it harder to write your malware... but imagine if you can write something in just a handful of different bytes, which then goes and triggers something else. You could have an extremely plausible attack that might need only a day's uploading to deliver. It makes no difference that there are 256! possible encryption keys, if most of them have the same result. ChrisA -- https://mail.python.org/mailman/listinfo/python-list