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: | CACMqXCKSSJxT9+HoD08O6+CRFUGWMRSmFhVaSFUesCfaxTdyXA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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 pgcrypto.so "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.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Bridget Frey | 2012-01-27 18:31:39 | Re: BUG #6200: standby bad memory allocations on SELECT |
Previous Message | Stefan Kaltenbrunner | 2012-01-27 18:10:20 | Re: pgcrypto decrypt_iv() issue |