Thread: crypt function crash on postgresql 9.3.20 and 10
If you send an asterisk in the crypt function, the function crashes.
example
i=# select crypt('123','*');
ОШИБКА: invalid salt
i=#
--
Regards,
Michael A. Manerko
Megalink Company, Engineer
318, Chehova street, Taganrog, Russia, 347932
tel work: +7 8634 431431 (ext 159)
tel mobile: +7 999 6939428
sip: 159@tagan.ru
www.tagan.ru
Seems more like pilot error than a bug....
On Fri, Feb 2, 2018 at 2:11 PM, Михаил Манерко <asper@tagan.ru> wrote:
> If you send an asterisk in the crypt function, the function crashes.
> example
>
> i=# select crypt('123','*');
> ОШИБКА: invalid salt
> i=#
Id does not crash, it just rejects your salt as invalid, probably
because it is ( does not look right to me, but I'm not in the mood for
fully checking that ).
TFM states 'Calculates a crypt(3)-style hash of password. When storing
a new password, you need to use gen_salt() to generate a new salt
value. To check a password, pass the stored hash value as salt, and
test whether the result matches the stored value.'
Are you doing that ?
Francisco Olarte.
On Fri, 2 Feb 2018, Михаил Манерко wrote:
> If you send an asterisk in the crypt function, the function crashes.
>
>
> example
>
> i=# select crypt('123','*');
> ОШИБКА: invalid salt
> i=#
The second argument is the salt, and you have not passed enough bits
for the default hash type.
i=> select crypt( '123', 'aa' );
crypt
---------------
aamrgyQfDFSHw
(1 row)
i=> select crypt( '123', 'a' );
ERROR: invalid salt
Regards,
Mike
>
> --
> Regards,
> Michael A. Manerko
>
> Megalink Company, Engineer
> 318, Chehova street, Taganrog, Russia, 347932
> tel work: +7 8634 431431 (ext 159)
> tel mobile: +7 999 6939428
> sip: 159@tagan.ru
> www.tagan.ru
>
>
>
-
Mike Porter
PGP Fingerprint: 139B 5431 9346 A577 C0F8 6C76 635D 6C9D 5ABB D433
Old Key: F4 AE E1 9F 67 F7 DA EA 2F D2 37 F3 99 ED D1 C2
On Feb 2, 2018 8:15 PM, "Mike Porter" <mike@udel.edu> wrote:
On Fri, 2 Feb 2018, Михаил Манерко wrote:The second argument is the salt, and you have not passed enough bitsIf you send an asterisk in the crypt function, the function crashes.
example
i=# select crypt('123','*');
ОШИБКА: invalid salt
i=#
for the default hash type.
i=> select crypt( '123', 'aa' );
crypt
---------------
aamrgyQfDFSHw
(1 row)
i=> select crypt( '123', 'a' );
ERROR: invalid salt
Regards,
Mike-
--
Regards,
Michael A. Manerko
Megalink Company, Engineer
318, Chehova street, Taganrog, Russia, 347932
tel work: +7 8634 431431 (ext 159)
tel mobile: +7 999 6939428
sip: 159@tagan.ru
www.tagan.ru
Mike Porter
PGP Fingerprint: 139B 5431 9346 A577 C0F8 6C76 635D 6C9D 5ABB D433
Old Key: F4 AE E1 9F 67 F7 DA EA 2F D2 37 F3 99 ED D1 C2
Hi,
Yeah Mike what u said is correct, the consistency of bits for generation of salt depends on algorithms like blow fish, md5 etc
Regards,
Pavan
Seems more like pilot error than a bug....
On Fri, Feb 2, 2018 at 2:11 PM, Михаил Манерко <asper@tagan.ru> wrote:
> If you send an asterisk in the crypt function, the function crashes.
> example
>
> i=# select crypt('123','*');
> ОШИБКА: invalid salt
> i=#
Id does not crash,
A crash either kills the server or at least drops your connection to the database. All this did was indicate invalid data (because you didn't use the API correctly) and put you back at a psql prompt.
it just rejects your salt as invalid, probably
because it is ( does not look right to me, but I'm not in the mood for
fully checking that ).
Well "The salt string also tells crypt() which algorithm to use." and "They use a random value, called the salt" - "*" looks like you trying to specify a specific salt value which is not allowed.
TFM states 'Calculates a crypt(3)-style hash of password. When storing
a new password, you need to use gen_salt() to generate a new salt
value. To check a password, pass the stored hash value as salt, and
test whether the result matches the stored value.'
Maybe someone could add:
HINT: use gen_salt() to generate the salt
to the code, though given that the "salt" argument also accepts a hashed password as input maybe complicates this.
David J.
On Feb 2, 2018 8:15 PM, "Mike Porter" <mike@udel.edu> wrote:On Fri, 2 Feb 2018, Михаил Манерко wrote:The second argument is the salt, and you have not passed enough bitsIf you send an asterisk in the crypt function, the function crashes.
example
i=# select crypt('123','*');
ОШИБКА: invalid salt
i=#
for the default hash type.
i=> select crypt( '123', 'aa' );
crypt
---------------
aamrgyQfDFSHw
(1 row)Hi,Yeah Mike what u said is correct, the consistency of bits for generation of salt depends on algorithms like blow fish, md5 etc
You sure? Don't have time to show otherwise but the docs suggest what you are doing is validating a store encrypted password as opposed to encrypting the provided one.
David J.
02.02.2018 17:55, David G. Johnston пишет:
On Feb 2, 2018 8:15 PM, "Mike Porter" <mike@udel.edu> wrote:On Fri, 2 Feb 2018, Михаил Манерко wrote:The second argument is the salt, and you have not passed enough bitsIf you send an asterisk in the crypt function, the function crashes.
example
i=# select crypt('123','*');
ОШИБКА: invalid salt
i=#
for the default hash type.
i=> select crypt( '123', 'aa' );
crypt
---------------
aamrgyQfDFSHw
(1 row)Hi,Yeah Mike what u said is correct, the consistency of bits for generation of salt depends on algorithms like blow fish, md5 etcYou sure? Don't have time to show otherwise but the docs suggest what you are doing is validating a store encrypted password as opposed to encrypting the provided one.David J.
function takes the text parameter
Should it fall from a 1-character long text?
-- Regards, Michael A. Manerko Megalink Company, Engineer 318, Chehova street, Taganrog, Russia, 347932 tel work: +7 8634 431431 (ext 159) tel mobile: +7 999 6939428 sip: 159@tagan.ru www.tagan.ru
On 02.02.2018 15:58, Михаил Манерко wrote:
02.02.2018 17:55, David G. Johnston пишет:On Feb 2, 2018 8:15 PM, "Mike Porter" <mike@udel.edu> wrote:On Fri, 2 Feb 2018, Михаил Манерко wrote:If you send an asterisk in the crypt function, the function crashes.
example
i=# select crypt('123','*');
ОШИБКА: invalid salt
i=#function takes the text parameter
Should it fall from a 1-character long text?
Yes, exactly!
This is similar to calling "sqrt(-1)". The parameter is invalid for the function, such thatthe function can not be performed.
Rainer
On 02.02.2018 15:58, Михаил Манерко wrote:02.02.2018 17:55, David G. Johnston пишет:On Feb 2, 2018 8:15 PM, "Mike Porter" <mike@udel.edu> wrote:On Fri, 2 Feb 2018, Михаил Манерко wrote:If you send an asterisk in the crypt function, the function crashes.
example
i=# select crypt('123','*');
ОШИБКА: invalid salt
i=#function takes the text parameter
Should it fall from a 1-character long text?
Yes, exactly!
This is similar to calling "sqrt(-1)". The parameter is invalid for the function, such thatthe function can not be performed.
Right.
Functions generally (rarely, never) have domain types created for them that would prevent invalid input values from even being created. Defining constraints on input values is usually left up to the documentation. In this case the documentation describes how to properly use the function. Used properly a single-character long text string should never be input into the function - so it wasn't deemed necessary to document that if one supplies such a string incorrectly that the function will error out. That seems like a reasonable decision (intentional or otherwise).
David J.
В Fri, 2 Feb 2018 08:29:08 -0700
"David G. Johnston" <david.g.johnston@gmail.com> пишет:
> On Fri, Feb 2, 2018 at 8:24 AM, Rainer Pruy <Rainer.Pruy@acrys.com>
> wrote:
>
> >
> > On 02.02.2018 15:58, Михаил Манерко wrote:
> >
> > 02.02.2018 17:55, David G. Johnston пишет:
> >
> > On Fri, Feb 2, 2018 at 7:50 AM, Pavan Teja
> > <pavan.postgresdba@gmail.com> wrote:
> >
> >>
> >>
> >> On Feb 2, 2018 8:15 PM, "Mike Porter" <mike@udel.edu> wrote:
> >>
> >> On Fri, 2 Feb 2018, Михаил Манерко wrote:
> >>
> >> If you send an asterisk in the crypt function, the function
> >> crashes.
> >>>
> >>>
> >>> example
> >>>
> >>> i=# select crypt('123','*');
> >>> ОШИБКА: invalid salt
> >>> i=#
> >>>
> >>
> >>
> > function takes the text parameter
> > Should it fall from a 1-character long text?
> >
> >
> > Yes, exactly!
> > This is similar to calling "sqrt(-1)". The parameter is invalid for
> > the function, such thatthe function can not be performed.
> >
>
> Right.
>
> Functions generally (rarely, never) have domain types created for
> them that would prevent invalid input values from even being
> created. Defining constraints on input values is usually left up to
> the documentation. In this case the documentation describes how to
> properly use the function. Used properly a single-character long text
> string should never be input into the function - so it wasn't deemed
> necessary to document that if one supplies such a string incorrectly
> that the function will error out. That seems like a reasonable
> decision (intentional or otherwise).
>
> David J.
However, in a postgresql 9.3.2, such a call does not lead to an error.
how then should the function respond to a call
select crypt('123',NULL);
this does not cause an error
On Friday, February 2, 2018, Michael <asper@tagan.ru> wrote:
However, in a postgresql 9.3.2, such a call does not lead to an error.
If you are saying 9.3.2 gives a result and 9.3.20 raises an error I suspect the response in 9.3.2 was bogus and giving an error instead of a bogus result was deemed the best fix.
how then should the function respond to a call
select crypt('123',NULL);
this does not cause an error
It probably returns null because I would hope the function is defined as strict.
David J.
В Fri, 2 Feb 2018 11:53:06 -0700
"David G. Johnston" <david.g.johnston@gmail.com> пишет:
> On Friday, February 2, 2018, Michael <asper@tagan.ru> wrote:
>
> >
> > However, in a postgresql 9.3.2, such a call does not lead to an
> > error.
>
>
> If you are saying 9.3.2 gives a result and 9.3.20 raises an error I
> suspect the response in 9.3.2 was bogus and giving an error instead
> of a bogus result was deemed the best fix.
>
>
> > how then should the function respond to a call
> > select crypt('123',NULL);
> > this does not cause an error
> >
>
> It probably returns null because I would hope the function is defined
> as strict.
>
> David J.
Thank you for the clarification. In any case, I've already fixed the
queries in my application to get around this behavior.
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> If you are saying 9.3.2 gives a result and 9.3.20 raises an error I suspect
> the response in 9.3.2 was bogus and giving an error instead of a bogus
> result was deemed the best fix.
A bit of diving in the git history says that behavior changed here:
Author: Noah Misch <noah@leadboat.com>
Branch: master Release: REL9_6_BR [1d812c8b0] 2015-10-05 10:06:29 -0400
Branch: REL9_5_STABLE Release: REL9_5_0 [4d6752277] 2015-10-05 10:06:33 -0400
Branch: REL9_4_STABLE Release: REL9_4_5 [4d95419e8] 2015-10-05 10:06:34 -0400
Branch: REL9_3_STABLE Release: REL9_3_10 [cc1210f0a] 2015-10-05 10:06:34 -0400
Branch: REL9_2_STABLE Release: REL9_2_14 [56232f987] 2015-10-05 10:06:35 -0400
Branch: REL9_1_STABLE Release: REL9_1_19 [48f6310bc] 2015-10-05 10:06:35 -0400
Branch: REL9_0_STABLE Release: REL9_0_23 [188e081ef] 2015-10-05 10:06:36 -0400
pgcrypto: Detect and report too-short crypt() salts.
Certain short salts crashed the backend or disclosed a few bytes of
backend memory. For existing salt-induced error conditions, emit a
message saying as much. Back-patch to 9.0 (all supported versions).
Josh Kupershmidt
Security: CVE-2015-5288
The 9.3.10 release notes do contain an entry about this.
regards, tom lane