Pure Python Data Mangling or Encrypting
Randall Smith
randall at tnr.cc
Sat Jun 27 13:08:46 EDT 2015
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
More information about the Python-list
mailing list