From tlyu@MIT.EDU Thu Sep 26 19:43:52 1996
Received: from dragons-lair.MIT.EDU (DRAGONS-LAIR.MIT.EDU [18.177.1.200]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id TAA03713 for <bugs@RT-11.MIT.EDU>; Thu, 26 Sep 1996 19:43:51 -0400
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by dragons-lair.MIT.EDU (8.6.13/8.6.9) with SMTP id TAA20321 for <krb5-bugs@dragons-lair.mit.edu>; Thu, 26 Sep 1996 19:43:50 -0400
Received: from TESLA-COIL.MIT.EDU by MIT.EDU with SMTP
id AA18743; Thu, 26 Sep 96 19:43:49 EDT
Received: by tesla-coil.MIT.EDU (5.x/4.7) id AA15611; Thu, 26 Sep 1996 19:43:46 -0400
Message-Id: <9609262343.AA15611@tesla-coil.MIT.EDU>
Date: Thu, 26 Sep 1996 19:43:46 -0400
From: tlyu@MIT.EDU
Reply-To: tlyu@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: security flaw in get_in_tkt: address verification
X-Send-Pr-Version: 3.99
System: SunOS tesla-coil 5.4 Generic_101945-37 sun4m sparc
To: krbdev@MIT.EDU
Subject: security flaw in get_in_tkt: address verification
verify_as_reply in get_in_tkt.c does not currently verify that the
address list in the reply is the same as was requested:
/* XXX || (!krb5_addresses_compare(context, addrs,
as_reply->enc_part2->caddrs)) */
This means that an attacker can intercept an AS_REQ, insert his own
address into the list, steal the resulting krbtgt from the client, and
use the stolen ticket from his own IP address.
Of course, this is not really a significant issue because it still
requires the attacker to steal the tickets or know the client's
password and, of course, having accomplished that an attacker could
easily forge the correct IP address anyway even if this vulnerability
did not exist. Frankly, I've been arguing since at latest 1990 that
Kerberos should not bother to include or check IP addresses in tickets
because it increases code complexity and does not increase security in
any significant way; the fact that this bug exists supports my point
further.
Barry
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: epeisach@MIT.EDU
Cc: krbdev@MIT.EDU
Date: Thu, 30 May 1996 13:22:45 EDT
From: Ezra Peisach <epeisach@MIT.EDU>
Question: Your code fragment implied that the code was commented out... I
Do you think that was to handle the multiple homed hosts out there now?
Yes, the code is commented out, and I have no idea why. Perhaps
someone commented it out because the addrs variable is no available,
but in fact the addresses are in the request structure, which is
available.
Barry
From: Sam Hartman <hartmans@MIT.EDU>
To: tlyu@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/31: security flaw in get_in_tkt: address verification
Date: Fri, 27 Sep 1996 02:37:20 -0400
I can't remember if I brought this up when I first saw this
this summer, and if I did, I may have been voted down.
Before fixing this bug, I would like to see an evaluation of
how difficult it would be to create a proxy gateway that sits on a
firewall and allows people behind the firewall to get tickets inside
the firewall for Kerberos realms outside the firewall. If the proxy
can add its address to the AS request, it may simplify the task of
forwarding subsiquent TGS requests, depdnding on how send_tgs
dealswith including the address in the ap_req.
I think that for Kerberos to be successful as an inter-domain
authentication system for people at organizations that deploy Kerberos
to share authenticated resources, some solution to the proxy problem
should be found eventually.
State-Changed-From-To: open-analyzed
State-Changed-By: tytso
State-Changed-When: Mon Nov 4 14:54:10 1996
State-Changed-Why: This is a known problem, but it's also not a big
deal, either....
Received: from dragons-lair.MIT.EDU (DRAGONS-LAIR.MIT.EDU [18.177.1.200]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id TAA03713 for <bugs@RT-11.MIT.EDU>; Thu, 26 Sep 1996 19:43:51 -0400
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by dragons-lair.MIT.EDU (8.6.13/8.6.9) with SMTP id TAA20321 for <krb5-bugs@dragons-lair.mit.edu>; Thu, 26 Sep 1996 19:43:50 -0400
Received: from TESLA-COIL.MIT.EDU by MIT.EDU with SMTP
id AA18743; Thu, 26 Sep 96 19:43:49 EDT
Received: by tesla-coil.MIT.EDU (5.x/4.7) id AA15611; Thu, 26 Sep 1996 19:43:46 -0400
Message-Id: <9609262343.AA15611@tesla-coil.MIT.EDU>
Date: Thu, 26 Sep 1996 19:43:46 -0400
From: tlyu@MIT.EDU
Reply-To: tlyu@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: security flaw in get_in_tkt: address verification
X-Send-Pr-Version: 3.99
Show quoted text
>Number: 31
>Category: krb5-libs
>Synopsis: security flaw in get_in_tkt: address verification
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: krb5-unassigned
>State: analyzed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Sep e 19:44:01 EDT 1996
>Last-Modified: Mon Nov e 14:54:51 EST 1996
>Originator: Tom Yu
>Organization:
mit>Category: krb5-libs
>Synopsis: security flaw in get_in_tkt: address verification
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: krb5-unassigned
>State: analyzed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Sep e 19:44:01 EDT 1996
>Last-Modified: Mon Nov e 14:54:51 EST 1996
>Originator: Tom Yu
>Organization:
Show quoted text
>Release: beta-7
>Environment:
>Environment:
System: SunOS tesla-coil 5.4 Generic_101945-37 sun4m sparc
Show quoted text
>Description:
From: "Barry Jaspan" <bjaspan@MIT.EDU>To: krbdev@MIT.EDU
Subject: security flaw in get_in_tkt: address verification
verify_as_reply in get_in_tkt.c does not currently verify that the
address list in the reply is the same as was requested:
/* XXX || (!krb5_addresses_compare(context, addrs,
as_reply->enc_part2->caddrs)) */
This means that an attacker can intercept an AS_REQ, insert his own
address into the list, steal the resulting krbtgt from the client, and
use the stolen ticket from his own IP address.
Of course, this is not really a significant issue because it still
requires the attacker to steal the tickets or know the client's
password and, of course, having accomplished that an attacker could
easily forge the correct IP address anyway even if this vulnerability
did not exist. Frankly, I've been arguing since at latest 1990 that
Kerberos should not bother to include or check IP addresses in tickets
because it increases code complexity and does not increase security in
any significant way; the fact that this bug exists supports my point
further.
Barry
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: epeisach@MIT.EDU
Cc: krbdev@MIT.EDU
Date: Thu, 30 May 1996 13:22:45 EDT
From: Ezra Peisach <epeisach@MIT.EDU>
Question: Your code fragment implied that the code was commented out... I
Do you think that was to handle the multiple homed hosts out there now?
Yes, the code is commented out, and I have no idea why. Perhaps
someone commented it out because the addrs variable is no available,
but in fact the addresses are in the request structure, which is
available.
Barry
Show quoted text
>How-To-Repeat:
Show quoted text
>Fix:
Show quoted text
>Audit-Trail:
From: Sam Hartman <hartmans@MIT.EDU>
To: tlyu@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/31: security flaw in get_in_tkt: address verification
Date: Fri, 27 Sep 1996 02:37:20 -0400
I can't remember if I brought this up when I first saw this
this summer, and if I did, I may have been voted down.
Before fixing this bug, I would like to see an evaluation of
how difficult it would be to create a proxy gateway that sits on a
firewall and allows people behind the firewall to get tickets inside
the firewall for Kerberos realms outside the firewall. If the proxy
can add its address to the AS request, it may simplify the task of
forwarding subsiquent TGS requests, depdnding on how send_tgs
dealswith including the address in the ap_req.
I think that for Kerberos to be successful as an inter-domain
authentication system for people at organizations that deploy Kerberos
to share authenticated resources, some solution to the proxy problem
should be found eventually.
State-Changed-From-To: open-analyzed
State-Changed-By: tytso
State-Changed-When: Mon Nov 4 14:54:10 1996
State-Changed-Why: This is a known problem, but it's also not a big
deal, either....
Show quoted text
>Unformatted: