Thread: crypt function crash on postgresql 9.3.20 and 10

crypt function crash on postgresql 9.3.20 and 10

From
Михаил Манерко
Date:
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



Re: crypt function crash on postgresql 9.3.20 and 10

From
Francisco Olarte
Date:
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.


Re: crypt function crash on postgresql 9.3.20 and 10

From
Mike Porter
Date:
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

Re: crypt function crash on postgresql 9.3.20 and 10

From
Pavan Teja
Date:


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

Re: crypt function crash on postgresql 9.3.20 and 10

From
"David G. Johnston"
Date:
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.

Re: crypt function crash on postgresql 9.3.20 and 10

From
"David G. Johnston"
Date:
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.

Re: crypt function crash on postgresql 9.3.20 and 10

From
Михаил Манерко
Date:
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=#

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

Re: crypt function crash on postgresql 9.3.20 and 10

From
Rainer Pruy
Date:

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.

Rainer

Re: crypt function crash on postgresql 9.3.20 and 10

From
"David G. Johnston"
Date:
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.

Re: crypt function crash on postgresql 9.3.20 and 10

From
Michael
Date:
В 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



Re: crypt function crash on postgresql 9.3.20 and 10

From
"David G. Johnston"
Date:
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.

Re: crypt function crash on postgresql 9.3.20 and 10

From
Michael
Date:
В 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.


Re: crypt function crash on postgresql 9.3.20 and 10

From
Tom Lane
Date:
"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