[5063] in Kerberos
Re: Secure telnet/PPP/Kerberos/STEL/... (was Re: STEL: Secure TELnet -- Call for Beta Testers)
daemon@ATHENA.MIT.EDU (Terje Normann Marthinussen)
Mon May 1 11:40:45 1995
To: kerberos@MIT.EDU
Date: 1 May 1995 14:53:12 GMT
From: terjem@stud.cs.uit.no (Terje Normann Marthinussen)
Joe Kovara (joek@kerby.ocsg.com) wrote:
: > 2) On multi user machines, someone could simply su to you and own your
: > Kerberos credentials, and connect to whatever machine you have. With something
: > like STEL, the attacker would need to plug through /dev/mem in an attempt
: > at finding your current encryption key and then use that to hijack your
: > connection or analyze the beginning of your connection where you typed your
: > password to the remote machine.
: Universal truth: if the "trusted" machine you are using (the one you typed
: your password at) has been compromised, life is over. Your session is
: compromised, and possibly your password. Doesn't matter whether you're
: using Kerberos or STEL or whatever.
: The Kerberos attack you describe is plausible, but life was over before
: you started your session, so why worry? At any rate, you don't _have_ to
: keep your credentials in a disk file, but that's typically the most
: convenient place to keep them. Even if I do take that route, I can get a
: service ticket without obtaining and storing a TGT, which means that,
: while the attacker may be able to obtain my initial session key (the one I
: used to authenticate with the telnet server), they won't be able to
: decrypt the session unless they've recorded the initial authentication
: exchange, because I'll be using a different session key after that.
: The above isn't perfect since, as you describe, if you do keep a service
: ticket on disk, the attacker could grab this and initiate a new session.
: You can either not keep credentials on disk, or destroy them once the
: session is initiated (assuming the telnet client has that option, or at
: least has a shell escape that allows you to delete the cred cache). I just
: described one of about a billion different combinations of threats and
: countermeasures; suffice it to say that, if done properly, Kerberos is as
: or more difficult to compromise than anything else I've seen.
Well...
Talking about compromised...
What would you define as compromised? Is a machine that has a program which
runs as root or is setuid root, which can be tricked into reading any file
on the system compromised?
There has been an awfull lot of those security holes discovered lately and
who knows how many which are still undiscovered. Leaving credentials on
disk is almost like putting your password there...
Thinking about it... that migth be an even larger problem with DCE/DFS.
I think you need to have credentials there all the time so you can create
new bindings for file system access.
Another issue is how the credentials are handled in memory.
In most login programs things are very strick about storing clear
text passwords in memory. But what happens if a program core dumps with
a credential in memory? Can you find it in the core file? There is usually
a lot of world readable core files laying around and people usually don't
look at them as potential security threats (which they are...).
Having your password (even one that expires within a short time) laying
around in clear text on disk or in memory isn't exactly improving security...
Terje Marthinussen
terjem@stud.cs.uit.no
