[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200715165718.GA8559@openwall.com>
Date: Wed, 15 Jul 2020 18:57:18 +0200
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: [PATCH 0/5] pam_tcb update
> > > On Thu, Jul 05, 2018 at 02:29:19AM +0300, Dmitry V. Levin wrote:
> > > > I've got a few patches for pam_tcb. Tested in Sisyphus.
On Wed, Jul 15, 2020 at 05:08:54PM +0300, Dmitry V. Levin wrote:
> I've finally managed to commit these changes.
Thank you!
On Wed, Jul 15, 2020 at 04:58:26PM +0300, Owl CVS (ldv) wrote:
> +#ifdef CRYPT_GENSALT_IMPLEMENTS_AUTO_ENTROPY
> + salt = crypt_gensalt_ra(pam_unix_param.crypt_prefix,
> + pam_unix_param.count, NULL, 0);
How exactly will this fail in case CRYPT_GENSALT_IMPLEMENTS_AUTO_ENTROPY
was defined at compile time, but the library in use at run time lacks
the support? I am concerned that this will silently return an empty
salt for some hash types, instead of crashing. Can we ensure there will
be a NULL pointer dereference crash, maybe by specifying NULL along with
non-zero size (and large enough that an implementation wouldn't likely
round it down to zero)?
Maybe we're better off not using CRYPT_GENSALT_IMPLEMENTS_AUTO_ENTROPY
and its corresponding feature at all, since we have our own code anyway?
Supporting both ways how tcb may be built increases the likelihood of
issues that we'd be responsible for.
I have similar concerns about CRYPT_GENSALT_IMPLEMENTS_DEFAULT_PREFIX.
What will happen if this is defined at compile time, but then the run
time library has no default?
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
