On Fri, Jan 27, 2012 at 8:10 PM, Stefan Kaltenbrunner <ste...@kaltenbrunner.cc> wrote: > On 01/27/2012 07:06 PM, Marko Kreen wrote: >> On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander <mag...@hagander.net> wrote: >>> On Fri, Jan 27, 2012 at 18:54, Marko Kreen <mark...@gmail.com> wrote: >>>> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner >>>> <ste...@kaltenbrunner.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
