Pure Python Data Mangling or Encrypting

[Randall Smith]

On 06/26/2015 08:21 PM, Chris Angelico wrote:
> On Sat, Jun 27, 2015 at 6:09 AM, Randall Smith <randall at 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.
>

Yes, that's true.  It's even an issue with AES, which uses padding to 
overcome.  That said, remember these are bytes going straight to disk. 
I'm really not concerned about 2 or 3 byte malware and the probability 
plunges after that.  And remember, normal use case is AES encrypted data.

Quite interesting.

Though I didn't mention it in the description, the storage server is 
appending a CRC32 checksum for routine integrity checks.  So by the time 
the data hits the disk, it will have added both a 256 byte translation 
table and a 4 byte checksum.  I think that would interfere with any 
extremely short malware.


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


Thankyou.  Nice points. I do think given the risks (there are always 
risks) discussed, a successful attack of this nature is not very likely. 
  Worse case, something that looks like this would land on the disk.

crc32 checksum + translation table + malware

with a generated base64 name and no extension.


Doesn't seem like much of a threat.   Much less likely than a bug in the 
standard Crytpo libraries.

-Randall