Re: pgcrypto decrypt_iv() issue
От | Stefan Kaltenbrunner |
---|---|
Тема | Re: pgcrypto decrypt_iv() issue |
Дата | |
Msg-id | 4F22E88C.1050507@kaltenbrunner.cc обсуждение исходный текст |
Ответ на | Re: pgcrypto decrypt_iv() issue (Marko Kreen <markokr@gmail.com>) |
Ответы |
Re: pgcrypto decrypt_iv() issue
|
Список | pgsql-bugs |
On 01/27/2012 07:06 PM, Marko Kreen wrote: > On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander <magnus@hagander.net> wrote: >> On Fri, Jan 27, 2012 at 18:54, Marko Kreen <markokr@gmail.com> wrote: >>> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner >>> <stefan@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... Stefan
В списке pgsql-bugs по дате отправления: