Kerberos SSH

Re: Server unknown

Re: Bug in 1.5.1 KDC is session key selection

Andreas:

That is a bug in OpenAFS that has been fixed in OpenAFS.
Heimdal already fixed its bug and 1.5 is performing the selection
correctly in the absence of a specific request by the application.
Heimdal should not be issuing session keys with the weakest key type
when the application is requesting that the KDC use its best judgment.

Jeffrey Altman

On 1/19/2012 3:08 AM, Andreas Haupt wrote:
> Hi Nico, Jeffrey,
> 
> well, I'm not really an expert here. This is what Andrew Deason wrote on
> the OpenAFS mailing list some time ago:
> 
> ---
> klog doesn't specify the enc type (for any code path, as far as I can
> tell). It appears to work if I set des-cbc-crc with
> krb5_get_init_creds_opt_set_etype_list, but shouldn't the kdc be
> restricted to the enctypes that actually exist for the princ, though, or
> am I misunderstanding something here?
> ---
> 
> The whole thread is archived here:
> https://lists.openafs.org/pipermail/openafs-info/2011-October/036935.html
> 
> So, klog.krb5 of the OpenAFS master branch has been fixed (tested with
> version 1.7.4). But even the latest stable versions of the 1.4 and 1.6
> trees don't have it (yet?).
> 
> To my understanding Heimdal 1.2.1 used the strongest enctype for the
> session key from the list of available keys in the db during the AS
> request. For the afs principal this is a des-cbc-... enctype. Heimdal
> 1.5 selects aes256-cts-hmac-sha1-96 which the buggy klog.krb5 versions
> don't expect. If I could tell Heimdal to use a specific des-cbc- enctype
> for all operations concerning the afs principal, this would restore the
> former behaviour (to my understanding ...).
> 
> Cheers & thanks
> Andreas
> 
> On Wed, 2012-01-18 at 11:59 -0600, Nico Williams wrote:
>> What etype list should be assumed when the client sends an empty one?
>>
>> I'm guessing that for TGS exchanges that should be {<ticket's session
>> key>, des-cbc-crc, des-cbc-md5}.
>>
>> For AS it'd be {<enctypes available for pre-auth for the given client
>> principal>}.
>>
>> But I need to know.
>>
>> Nico
>> --
> 

build error

I try to build the 1.5, 1.5.1 or 1.5.2 heimdal package on a i686
architecture (Scientific Linux SL release 5.5)
but I always get the same problem:

e.g. in heimdal-1.5.2/lib/ipc

libtool: link: gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wbad-function-cast -Wmissing-declarations -Wnested-externs -g -O2 -o
.libs/tc tc.o -pthread  ./.libs/libheim-ipcc.a
/root/heimdal-1.5.2/base/.libs/libheimbase.so
/root/heimdal-1.5.2/lib/roken/.libs/libroken.so
../../lib/vers/.libs/libvers.a ../../lib/roken/.libs/libroken.so
-lcrypt -lresolv -pthread -Wl,-rpath -Wl,/usr/heimdal/lib
/root/heimdal-1.5.2/base/.libs/libheimbase.so: undefined reference to
`__sync_sub_and_fetch_4'
/root/heimdal-1.5.2/base/.libs/libheimbase.so: undefined reference to
`__sync_add_and_fetch_4'
collect2: ld returned 1 exit status
make: *** [tc] Error 1

(on a x86_64 architecture, the "make" has no problems).

Any ideas how to solve this?

--

-- 
Ronny Blomme - Ronny.Blomme <at> elis.UGent.be
system manager
UGent/ELIS - IMEC
ELIS - Ghent University - Ghent, Belgium
tel: +32/9/264.42.35 fax: +32/9/264.35.94 gsm: 0472/27.99.67
http://www.elis.UGent.be/RonnyBlomme

***********************************************************************
This e-mail and/or its attachments may contain confidential information.
It is intended solely for the intended addressee(s). Any use of the
information contained herein by other persons is prohibited.
Both IMEC vzw and Ghent University do not accept any liability for the
contents of this mail and/or its attachments.

ssh or kerberos library searching for default realm (but why?)

Scanario (heimdal 1.5.1 and ssh 5.7p1 with Simon's patches):

$ ./kinit haba <at> NADA.KTH.SE
... Password: xxxx

$ ./ssh -v -v -o GSSAPIKeyExchange=yes haba <at> computer.pdc.kth.se
(...)
unable to find realm of host habadrom
(...)
=> exit

habadrom is my local machine. It does not need to be in any realm for
kerberos to be useful. I have a perfectly working ticket in the
ticket cache. Is it ssh or the heimdal libraries that think that
they need the local realm of the local computer? If I supply a
fake realm

$ cat > FAKE << EOF
[libdefaults]
default_realm=FAKE
EOF
$ KRB5_CONFIG=FAKE ./ssh -v -v -o GSSAPIKeyExchange=yes haba <at> computer.pdc.kth.se

then it works, which proves that the knowledge of a real realm of
the local hostname is completely unneccessary. Do I now need to
ship a fake krb5.conf to cygwin users (whose computers typically
are not in some default realm at all)?

Harald.

heimdal 1.5.1 not building under cygwin

Doing some experiments with configure options then gave the following combination which seems to work (at
least it compiles):

cygwin# ./configue --enable-shared --enable-static --with-x --with-readline
--with-readline-lib=/usr/lib --with-readline-include=/usr/include/readline

However I am not happy with the output of krb5-config --libs, at least heimbase and sqlite3 seem to be missing.

Harald.

heimdal 1.5.1 not building under cygwin

I have tried building under cygwin (configure --enable-static
--enable-dynamic) and it breaks somewhere in readline (does not matter
if I use --with-readline-inlcludes=/usr/include/readline/ or not).
Currently I'm trying to disable any notice of editline so that really
readline is used.

If someone has a method to build 1.5.1 under cygwin I'd be happy to
copy it (and my virtual win* box is painfully slow).

Harald.

[Broken test case] Cryptic error message, fallback handling issue

Hello list,

Just reporting about a strange case of behavior difference between
Heimdal and MIT Kerberos implementations, that I stumbled upon. Of
course, this is assuming a somewhat broken scenario in the first place
(apache virtual hosts => inconsistent DNS & rDNS within a realm), but I
figured this might interest other people, and myself was looking for
further input.

-------------------------------

Environment specs :
- OS : FreeBSD 8.2-RELEASE / amd64
- Tested Kerberos versions :
 - Heimdal 1.1.0 (default, as confirmed from the version string embedded
in /usr/lib/libkrb5.so)
 - MIT 1.9 (Using security/krb5)
- KDC : Windows Server 2003 (default enc_type : ARCFOUR-HMAC-MD5)

-------------------------------

Scenario :
Single sign-on for a web application on Apache 2.2.17 + mod_auth_kerb
5.4 (Each time re-built with each different version of Kerberos)

The KDC is an AD domain controller. User accounts and keytab generation
process have all been tested and confirmed through other means (other
applications running seamlessly, with other OSes (OpenBSD, RedHat))

-------------------------------

Application configuration :
- Kerberos environment (besides realm definition) :
 - default_realm = KERBEROS.REALM
 - dns_lookup_realm = false
 - dns_lookup_kdc = false
- Application hosted on server "server.domain", DNS and rDNS set properly
- Application hostname "applicaiton.domain" is a CNAME to server.domain
- Virtualhost dedicated to the application, specified in Apache
 -> KrbServiceName set as HTTP/application.domain <at> KERBEROS.REALM (to
ensure the queried URL matches the used SPN)
 -> KrbLocalUserMapping on
 -> KrbSaveCredentials on
- HTTP service keytab was generated using ARCFOUR-HMAC-MD5

Note : For kicks, I tested DES-CBC-MD5, but this fails miserably with
decryption integrity check errors, as if it didn't acknowledge it, and
tried decrypting data as if it was ARCFOUR-HMAC-MD5... I found this
weird, but I didn't bother because this was as good an excuse as any
other to NOT use DES.

-------------------------------

Use cases (when accessing "application.domain") :
- Mozilla Firefox (latest) : No problem
- Google Chrome (latest) : No problem
- IE 7, IE 8 : IE tries unified authentication, which involves (as far
as what a tcpdump will reveal) confirming DNS and rDNS, then using the
final lookup result to do a Kerberos query (i.e, asking on behalf of
"HTTP/server.domain" instead of "HTTP/application.domain")

In the IE cases :
- Using Heimdal, authentication will blow up fatally, yielding either an
error 500 or 401 and the following cryptic error message (caught from
apache logs) :
   gss_display_name() failed:  An invalid name was supplied (, unknown
mech-code 0 for mech unknown)

- Using MIT, single sign-on will fail (as consistency requirements for a
trusted domain member are not met), but successive password dialogs
indicative of IE fumbling around and downgrading its requirements each
time, proceed, until we reach insecure basic authentication, which
ultimately succeeds.

-------------------------------

Of course, ultimately, the problem does not occur at all when giving a
dedicated IP to the application, and having a proper DNS setup for the
application hostname, however the difference in behavior between
implementations was jarring, to say the least.

So, I wanted to have a little more input if anyone was knowledgeable
about this topic. :)

Many thanks for your time,
--

-- 
Stephane LAPIE, EPITA SRS, Promo 2005
"Even when they have digital readouts, I can't understand them."
--MegaTokyo

Close memory leaks in the kadm5 library

valgrind revealed a bunch of memory leaks in a simple kadmin client (part
of the pam-krb5 test suite, to set a principal's password expired), all of
which traced to two places.

First, if a ticket cache were not passed into kadm5_c_init_with_context,
kadm5_connect would create a temporary ticket cache for the kadmin service
ticket.  This, via get_new_cache, would create a temporary unique memory
cache.  But, on completion of the connection, that cache was only closed,
not destroyed, which left its contents still allocated.  Since this is a
temporary, unique memory cache, there's no reason to leave it allocated
once the function completes, so close it with krb5_cc_destroy instead.

Second, kadm5_c_destroy was not freeing the kadm5_client_context itself,
just its contents.

After the attached patch, a simple kadmin client (and, indeed, the entire
pam-krb5 test suite) run under valgrind with --leak-check=full
--show-reachable=yes does not uncover any memory leaks not covered by the
following suppressions:

{
   heimdal-krb5-init-context-once
   Memcheck:Leak
   fun:*alloc
   ...
   fun:init_context_once
}
{
   heimdal-krb5-reg-plugins-once
   Memcheck:Leak
   fun:*alloc
   ...
   fun:krb5_plugin_register
   fun:reg_def_plugins_once
}
{
   heimdal-krb5-openssl-init
   Memcheck:Leak
   fun:*alloc
   obj:*
   fun:CRYPTO_*alloc
}

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

kdc-tester dependency on libheimbase

make[1]: Entering directory `/home/eagle/dvl/heimdal/kdc'
  CCLD   kdc-tester
/usr/bin/ld: kdc-tester.o: undefined reference to symbol 'heim_array_get_type_id <at>  <at> HEIMDAL_BASE_1.0'
/usr/bin/ld: note: 'heim_array_get_type_id <at>  <at> HEIMDAL_BASE_1.0' is defined in DSO
/home/eagle/dvl/heimdal/base/.libs/libheimbase.so.1 so try adding it to the linker command line
/home/eagle/dvl/heimdal/base/.libs/libheimbase.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

kdc-tester uses symbols from libheimbase directly, so needs to be linked
with it explicitly.  Patch attached.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

Current (?) Git repository fails to build on Debian

I'm trying to build the master branch of git://svn.h5l.org/heimdal.git to
test some patches, and the build is failing in lib/asn1:

make[2]: Entering directory `/home/eagle/dvl/heimdal/lib/asn1'
  YACC   asn1parse.c
cd . && perl ../../cf/make-proto.pl -q -P comment -o der-protos.h der_locl.h der.c der.h der_get.c
der_put.c der_free.c der_length.c der_copy.c der_cmp.c der_format.c heim_asn1.h extra.c
template.c timegm.c || rm -f der-protos.h
Legacy library getopts.pl will be removed from the Perl core distribution in the next major release.
Please install the separate libperl4-corelibs-perl package. It is being used at
../../cf/make-proto.pl, line 5.
cd . && perl ../../cf/make-proto.pl -q -P comment -p der-private.h der_locl.h der.c der.h der_get.c
der_put.c der_free.c der_length.c der_copy.c der_cmp.c der_format.c heim_asn1.h extra.c
template.c timegm.c || rm -f der-private.h
Legacy library getopts.pl will be removed from the Perl core distribution in the next major release.
Please install the separate libperl4-corelibs-perl package. It is being used at
../../cf/make-proto.pl, line 5.
  CC     asn1parse.o
asn1parse.y: In function ‘yyparse’:
asn1parse.y:244:5: warning: implicit declaration of function ‘error_message’ [-Wimplicit-function-declaration]
asn1parse.y:244:5: warning: nested extern declaration of ‘error_message’ [-Wnested-externs]
  CC     gen.o
  CC     gen_copy.o
  CC     gen_decode.o
  CC     gen_encode.o
  CC     gen_free.o
  CC     gen_glue.o
  CC     gen_length.o
  CC     gen_seq.o
  CC     gen_template.o
  CC     hash.o
  CC     lex.o
lex.l: In function ‘yylex’:
lex.l:261:8: warning: implicit declaration of function ‘error_message’ [-Wimplicit-function-declaration]
lex.l:261:8: warning: nested extern declaration of ‘error_message’ [-Wnested-externs]
lex.l: At top level:
lex.l:286:1: warning: no previous prototype for ‘error_message’ [-Wmissing-prototypes]
lex.l:286:1: warning: conflicting types for ‘error_message’ [enabled by default]
lex.l:261:8: note: previous implicit declaration of ‘error_message’ was here
  CC     main.o
  CC     symbol.o
  CCLD   asn1_compile
gen_decode.o: In function `find_tag':
/home/eagle/dvl/heimdal/lib/asn1/gen_decode.c:146: undefined reference to `lex_error_message'
symbol.o: In function `checkfunc':
/home/eagle/dvl/heimdal/lib/asn1/symbol.c:96: undefined reference to `lex_error_message'
collect2: ld returned 1 exit status
make[2]: *** [asn1_compile] Error 1
make[2]: Leaving directory `/home/eagle/dvl/heimdal/lib/asn1'

Something weird seems to be going on here, as the asn1parse.y and lex.l
source files reference lex_error_message, not error_message, but in the
generated *.c files all occurrences of lex_error_message have been changed
to error_message.  Is this some sort of weird behavior of Bison and Flex
that other people are not seeing because you're using BSD versions of the
tools?

Also, the last change in the Heimdal repository seems to be from November
19th, so I'm a bit worried that I'm looking in the wrong place.

(Note also the Perl error messages above.  The code should probably be
converted to Getopt::Long at some point, as the Perl folks are deprecating
the Perl 4 libraries.)

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>