Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Randall Smith <randall@tnr.cc>
Subject: Re: Pure Python Data Mangling or Encrypting
Date: Sat, 27 Jun 2015 12:08:46 -0500
References: <mmcagn$aa5$1@ger.gmane.org> <q67loadve6lsrh672u47omr04tvqttt6jd@4ax.com> <mailman.29.1435170987.3674.python-list@python.org> <558b7e85$0$1648$c3e8da3$5496439d@news.astraweb.com> <mailman.42.1435206516.3674.python-list@python.org> <558bc912$0$2899$c3e8da3$76491128@news.astraweb.com> <slrnmonkip.1nu.jon+usenet@frosty.unequivocal.co.uk> <558c1a7e$0$1668$c3e8da3$5496439d@news.astraweb.com> <slrnmoo7ev.1nu.jon+usenet@frosty.unequivocal.co.uk> <CAPTjJmqOzLTv9cFFKjV-BLtaFZhEZ4B870ALqNMmanCEN-VqXA@mail.gmail.com> <mailman.89.1435280528.3674.python-list@python.org> <558d86b0$0$1659$c3e8da3$5496439d@news.astraweb.com> <mmkbij$dpm$1@ger.gmane.org> <CAPTjJmon4abegr01-+mo5aLML+gA3wnR_+_kTTU7gGuCn=xrDA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
In-Reply-To: <CAPTjJmon4abegr01-+mo5aLML+gA3wnR_+_kTTU7gGuCn=xrDA@mail.gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.141.1435424948.3674.python-list@python.org>
Lines: 74
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:93252

On 06/26/2015 08:21 PM, Chris Angelico wrote:
> On Sat, Jun 27, 2015 at 6:09 AM, Randall Smith <randall@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