On 06/26/2015 08:21 PM, Chris Angelico wrote:
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.
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
--
https://mail.python.org/mailman/listinfo/python-list
