Skip site navigation (1) Skip section navigation (2)

Re: pgcrypto decrypt_iv() issue

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres-Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: pgcrypto decrypt_iv() issue
Date: 2012-01-27 18:18:35
Message-ID: (view raw or whole thread)
Lists: pgsql-bugs
On Fri, Jan 27, 2012 at 8:10 PM, Stefan Kaltenbrunner
<stefan(at)kaltenbrunner(dot)cc> wrote:
> On 01/27/2012 07:06 PM, Marko Kreen wrote:
>> On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> On Fri, Jan 27, 2012 at 18:54, Marko Kreen <markokr(at)gmail(dot)com> wrote:
>>>> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
>>>> <stefan(at)kaltenbrunner(dot)cc> wrote:
>>>>> On 01/27/2012 04:20 PM, Marko Kreen wrote:
>>>>>> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
>>>>>> Yeah, it should be fixed.  But note that "random data" is part of
>>>>>> decrypt() spec - the validation it can do is a joke.
>>>>>> Its more important to do proper checks in encrypt() to avoid invalid
>>>>>> stored data, but there the recommended modes (CBC, CFB) can work
>>>>>> with any length data, so even there the impact is low.
>>>>> I agree - but in my case the input to those functions is actually coming
>>>>> from external untrusted systems - so if the data is (completely) invalid
>>>>> really want to get a proper error message instead of random memory content.
>>>> You *will* get random memory content.  If your app is exploitable with
>>>> invalid data, you *will* get exploited.  The decrypt() checks are
>>>> more for developer convenience than anything more serious.
>>> Hold on. I hope there's some misunderstanding here.
>>> I hope you are you saying that feeding random data to the decrypt
>>> functions should be expected to return random data out of previously
>>> free()d areas? Surely you're not?
>>> Obviouly, if you send in invalid data or an invalid key, it will
>>> decrypt into incorrect data, that goes without saying. But it should
>>> still be the same block size and not contain random unrelated memory
>>> blocks, shouldn' it?
>> Yes, it should not contain unrelated data.
> hmm - see the last example I had in my original report - not sure i
> consider the path to "related" data and I most definitly do
> not expect to get that back from sending invalid data to the database...

Yeah, the bug causes return of palloced but uninitialized data.
That needs to be fixed.


In response to

pgsql-bugs by date

Next:From: Bridget FreyDate: 2012-01-27 18:31:39
Subject: Re: BUG #6200: standby bad memory allocations on SELECT
Previous:From: Stefan KaltenbrunnerDate: 2012-01-27 18:10:20
Subject: Re: pgcrypto decrypt_iv() issue

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group