crypt function crash on postgresql 9.3.20 and 10

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:

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

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

On Fri, Feb 2, 2018 at 7:38 AM, Francisco Olarte <folarte@peoplecall.com>
wrote:

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 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=#

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)

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 Fri, Feb 2, 2018 at 7:50 AM, Pavan Teja <pavan.postgresdba@gmail.com <mailto:pavan.postgresdba@gmail.com>>wrote:

On Feb 2, 2018 8:15 PM, "Mike Porter" <mike@udel.edu <mailto: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=#

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)

      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.
​

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 Fri, Feb 2, 2018 at 7:50 AM, Pavan Teja
<pavan.postgresdba@gmail.com <mailto:pavan.postgresdba@gmail.com>>wrote:

On Feb 2, 2018 8:15 PM, "Mike Porter" <mike@udel.edu
<mailto: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 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.

В 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