Re: Put a limit to ticket life span.

2012-10-27 Thread Russ Allbery 
Mats Erik Andersson  writes:

> The patch in this thread intended to address this, and the matter still
> is bound by the administrator's decision. Perhaps the factor five should
> be replaced by ten as breaking point, but it was chosen as a possible
> mode of detecting an exsessive time limit. I do not now for sure. Let me
> add that another idea for a solution was stated in [1], but it never
> caught any attention.

Oh, I see.

I'm actually surprised that *all* Kerberos clients don't send an empty
ticket lifetime by default.  That seems like a sensible thing to do, since
then the client gets whatever the server default is.

> Luckily, collecting my thoughts for this answer, I have found I third
> way of attack, which seems to be what you are looking for. It copes in
> the desired way with the Solaris clients, and leaves all other
> untouched.

Yes, this looks right and like what I would expect (assuming that
ticketlife is the server configuration for the maximum ticket life).

-- 
Russ Allbery (r...@stanford.edu) 

___
Help-shishi mailing list
Help-shishi@gnu.org
https://lists.gnu.org/mailman/listinfo/help-shishi

Re: Put a limit to ticket life span.

2012-10-27 Thread Mats Erik Andersson 
lördag den 27 oktober 2012 klockan 12:42 skrev Russ Allbery detta:
> Mats Erik Andersson  writes:
> 
> > I have brought this up before:
> 
> >   A native Solaris' Kerberos ticket request, will be granted
> >   by "shishid" with a life span of 25 years, since libshishi
> >   does not perform sanitation. It is "shishid" that malfunc-
> >   tions, not the external client!
> 
> > The following patch resets the requested expiration time for
> > any request that asks for more than a five-fold of the default
> > life span, simply by resetting the interval to the configured
> > default value. I have tested this with "kinit" on OpenIndiana
> > and "shishid" on Debian.
> 
> Assuming that I understood this correctly (I've not studied the code)
> 
> Maximum ticket lifetime should really be something that the KDC
> administrator can configure, since this is closely tied with local
> security policies and with the basic security tradeoff of Kerberos (short
> ticket expirations but no revocation facility).  For both MIT and Heimdal,
> the maximum ticket lifetime is configurable per principal.
> 
> Assuming 5x the default expiration caps the problem, but isn't the
> configuration that I suspect most people use.  Most sites in my experience
> set the maximum ticket lifetime to the same as the default and use
> renewable tickets if they want to allow tickets to last longer than that.

The problem is this:

  * Solaris' kinit does not per se, unless told by 'kinit -l 27m',
send any time limit information to "shishid".

  * shishid is not clever enough, or was not programmed carefully
enough, to recognize the absence of a time limit field. It will
therefore set an infinite time limit, resulting in a validity
for some 25 years with present epoch counters.

Seen from the programmer's horizon, in "lib/internal.h" there is library
internal access to the configurable field "handle->timelimit". However,
"src/kdc.c" is not allowed to access this. Let me trace some calls:

  * A request sent without a field "till", will cause shishi_kdcreq_tillc()
to return "(time_t) -1", i.e., infinite time in all senses.

  * In "src/kdc.c, lines 783--787" this infinite value is uncritically
passed on

 
shishi_encticketpart_endtime_set(shishi_generalized_time(shishi_kdcrec_tillc()))

leading to the present mishap.

The patch in this thread intended to address this, and the matter still
is bound by the administrator's decision. Perhaps the factor five should
be replaced by ten as breaking point, but it was chosen as a possible
mode of detecting an exsessive time limit. I do not now for sure. Let me
add that another idea for a solution was stated in [1], but it never caught
any attention.

Luckily, collecting my thoughts for this answer, I have found I third
way of attack, which seems to be what you are looking for. It copes
in the desired way with the Solaris clients, and leaves all other
untouched.

Best regards,
  Mats Erik Andersson

[1] http://lists.gnu.org/archive/html/help-shishi/2012-08/msg00058.html


>From 849163741ad8efbcfccbba989eebee3c3f5149f2 Mon Sep 17 00:00:00 2001
From: Mats Erik Andersson 
Date: Sat, 27 Oct 2012 23:14:43 +0200
Subject: [PATCH] kdcreq: Initiate ticket life as finite.

Some clients transmit requests without the field "till".
Assign a ticket life span for such requests based on
the servers configuration.
---
 lib/kdcreq.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/kdcreq.c b/lib/kdcreq.c
index affef41..87b4279 100644
--- a/lib/kdcreq.c
+++ b/lib/kdcreq.c
@@ -616,7 +616,7 @@ shishi_kdcreq_tillc (Shishi * handle, Shishi_asn1 kdcreq)
 {
   char *till;
   size_t tilllen;
-  time_t t = (time_t) - 1;
+  time_t t = time (NULL) + handle->ticketlife;
   int res;
 
   res = shishi_kdcreq_till (handle, kdcreq, &till, &tilllen);
-- 
1.7.2.5


___
Help-shishi mailing list
Help-shishi@gnu.org
https://lists.gnu.org/mailman/listinfo/help-shishi

Re: Put a limit to ticket life span.

2012-10-27 Thread Russ Allbery 
Mats Erik Andersson  writes:

> I have brought this up before:

>   A native Solaris' Kerberos ticket request, will be granted
>   by "shishid" with a life span of 25 years, since libshishi
>   does not perform sanitation. It is "shishid" that malfunc-
>   tions, not the external client!

> The following patch resets the requested expiration time for
> any request that asks for more than a five-fold of the default
> life span, simply by resetting the interval to the configured
> default value. I have tested this with "kinit" on OpenIndiana
> and "shishid" on Debian.

Assuming that I understood this correctly (I've not studied the code)

Maximum ticket lifetime should really be something that the KDC
administrator can configure, since this is closely tied with local
security policies and with the basic security tradeoff of Kerberos (short
ticket expirations but no revocation facility).  For both MIT and Heimdal,
the maximum ticket lifetime is configurable per principal.

Assuming 5x the default expiration caps the problem, but isn't the
configuration that I suspect most people use.  Most sites in my experience
set the maximum ticket lifetime to the same as the default and use
renewable tickets if they want to allow tickets to last longer than that.

-- 
Russ Allbery (r...@stanford.edu) 

___
Help-shishi mailing list
Help-shishi@gnu.org
https://lists.gnu.org/mailman/listinfo/help-shishi

Put a limit to ticket life span.

2012-10-27 Thread Mats Erik Andersson 
I have brought this up before:

  A native Solaris' Kerberos ticket request, will be granted
  by "shishid" with a life span of 25 years, since libshishi
  does not perform sanitation. It is "shishid" that malfunc-
  tions, not the external client!

The following patch resets the requested expiration time for
any request that asks for more than a five-fold of the default
life span, simply by resetting the interval to the configured
default value. I have tested this with "kinit" on OpenIndiana
and "shishid" on Debian.

Regards,
  Mats Erik Andersson


>From c2fe645f49e803ee331e3595c03a408b1140096b Mon Sep 17 00:00:00 2001
From: Mats Erik Andersson 
Date: Sat, 27 Oct 2012 16:38:18 +0200
Subject: [PATCH] encticketpart: Limit excessive life span.

---
 lib/encticketpart.c |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/lib/encticketpart.c b/lib/encticketpart.c
index 4f7dc8e..4752caf 100644
--- a/lib/encticketpart.c
+++ b/lib/encticketpart.c
@@ -288,7 +288,9 @@ shishi_encticketpart_authtime_set (Shishi * handle,
  * @encticketpart: input EncTicketPart variable.
  * @endtime: character buffer containing a generalized time string.
  *
- * Set the EncTicketPart.endtime to supplied value.
+ * Set the EncTicketPart.endtime to a supplied value.
+ * A life span in excess of five default ticket life spans
+ * is reset to the configured default value.
  *
  * Return value: Returns %SHISHI_OK iff successful.
  **/
@@ -298,6 +300,14 @@ shishi_encticketpart_endtime_set (Shishi * handle,
  const char *endtime)
 {
   int res;
+  time_t limit, asked;
+
+  asked = shishi_generalize_ctime (handle, endtime);
+  limit = time (NULL) + handle->ticketlife;
+
+  /* Is the life span excessive?  Then standardize it.   */
+  if (asked > time (NULL) + 5 * handle->ticketlife)
+endtime = shishi_generalize_time (handle, limit);
 
   res = shishi_asn1_write (handle, encticketpart, "endtime",
   endtime, SHISHI_GENERALIZEDTIME_LENGTH);
-- 
1.7.2.5


___
Help-shishi mailing list
Help-shishi@gnu.org
https://lists.gnu.org/mailman/listinfo/help-shishi