Copy: harshawardhan.rk@gmail.com (Harshawardhan Kulkarni)
Copy: kerberos@mit.edu (kerberos@mit.edu)

Looks like it might also be in the global master_keyblock in the
server_kdb.c file.

Chris


------ Original Message ------
From: "Chris Hecker" <checker@d6.com>
To: "Nico Williams" <nico@cryptonector.com>
Cc: "Harshawardhan Kulkarni" <harshawardhan.rk@gmail.com>;
"kerberos@mit.edu" <kerberos@mit.edu>
Sent: 2020-06-11 15:54:32
Subject: Re[2]: MIT Kerberos Master principal deletion

I don't think it would make it harder.

I just mean because you won't be able to set a breakpoint at a function that uses the key, you'll have to actually chase it around in memory (assuming you use something like gcore to dump it as fast as possible without regard to where it is executing

when it's dumped).

If I was doing this live, I'd set a breakpoint on some function that used the key to decrypt and then inspect there, but with a core file you'll need to make sure you can find all the structures first.

Is realm_mkey in the kdc_realm_data struct the one he wants?

Chris

------ Original Message ------
From: "Nico Williams" <nico@cryptonector.com>
To: "Chris Hecker" <checker@d6.com>
Cc: "Harshawardhan Kulkarni" <harshawardhan.rk@gmail.com>; "kerberos@mit.edu" <kerberos@mit.edu>
Sent: 2020-06-11 15:31:28
Subject: Re: MIT Kerberos Master principal deletion

On Thu, Jun 11, 2020 at 10:19:39PM +0000, Chris Hecker wrote:

Maybe dump the core of the running process so you don't accidentally crash >>> it while trying to debug it live? But that would make finding it in memory
even harder...

I don't think it would make it harder.

BTW, we should make it much harder to delete important principals...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)