[38787] in Kerberos
Re: Avoiding Pre-Auth/Auth Principal State Disclosure
daemon@ATHENA.MIT.EDU (Chris Hecker)
Wed Jul 1 15:58:12 2020
MIME-Version: 1.0
In-Reply-To: <c2bc7b92-4963-4a8d-e22c-f24de80ca84a@mit.edu>
From: Chris Hecker <checker@d6.com>
Date: Wed, 1 Jul 2020 12:55:36 -0700
Message-ID: <CAOdMLc1FOBDXxBn3wjWHw8nG=0RLjsmTD8OEde0sNS27b+WjbA@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
> For example, if we treated single-component principals as users,
anyone with a user/admin principal (or user/root, which has no status in
the code but is a common convention for elevated access) would probably
still be detectable by an attacker.
Not sure I follow this, why wouldn’t they be treated like a normal princ if
we had this obscurity feature? I remember assuming vague errors would fix
this but then discovering it didn’t, which was surprising. I build my KDC
myself so I wasn’t worried about that part, I just was surprised it wasn’t
possible.
Chris
On Wed, Jul 1, 2020 at 12:39 Greg Hudson <ghudson@mit.edu> wrote:
> On 7/1/20 1:53 AM, Eric Hattemer wrote:
> > I know pre-auth is a special case where you'd need to provide a
> > plausible challenge for non-existent accounts. But is there maybe a
> > setting to treat unknown principals as if they had pre-auth disabled,
> > request a password, and just send back invalid password / encryption
> > failed no matter what?
>
> We don't have a setting like that. The closest nod we have in the code
> to this desire is a "vague errors" setting for the KDC, which can only
> be turned on at compile time (or via ptrace, I guess) and causes the KDC
> to yield generic errors instead of useful ones. But that setting still
> allows an attacker to easily distinguish between "client principal
> requires preauth" and "client principal not found".
>
> Because the Kerberos principal namespace isn't formally divided between
> users and services, any obscurity feature would probably have some edge
> cases. For example, if we treated single-component principals as users,
> anyone with a user/admin principal (or user/root, which has no status in
> the code but is a common convention for elevated access) would probably
> still be detectable by an attacker.
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
