Target realm gets overwritten

[Alibek Jorajev]

hi !

I am using KRB5 API to fetch TGT and then GSS API to generate negotiate tokens.
(then I add these tokens into HTTP headers when needed). I am using Heimdal v. 1.4.

This works in all cases, but in one specific scenario,

Scenario (I just made up names):

- Client ([hidden email]) obtains TGT from KDC1:   krbtgt/[hidden email]

- Client obtains a cross-realm ticket-granting ticket: krbtgt/[hidden email]

- Client obtains service ticket:  HTTP/[hidden email]

This works, but next time I call GSS API,  cached service tickets are ignored
and for each and every resource a new service ticket is obtained (thus flooding KDC server and also filling up local client's cache).


After debugging and code reading, I have established the root cause:

1. new requests are done because "check_cc" function (in check_cc.c file) is given a wrong server name:

check_cc(krb5_context context, krb5_flags options, krb5_ccache ccache, krb5_creds *in_creds, krb5_creds *out_creds)
gets this "HTTP/[hidden email]" instead of "HTTP/[hidden email]"


2.  "in_creds->server->realm" gets overridden in import_name.c file, in function _gsskrb5_canon_name:

When gsskrb5_get_creds calls _gsskrb5_canon_name function, it passes correct creds with "EAST.TESTNET.NET" as a realm.
but here, in this place:


    /* If its not a hostname */
    if (krb5_principal_get_type(context, p) != MAGIC_HOSTBASED_NAME_TYPE) {
    ret = krb5_copy_principal(context, p, out);
    } else if (!use_dns) {
    ret = krb5_copy_principal(context, p, out);
    if (ret)
        goto out;
    krb5_principal_set_type(context, *out, KRB5_NT_SRV_HST);
    if (sourcename)
        ret = krb5_principal_set_realm(context, *out, sourcename->realm);
    } else {
     .......

"sourcename" is client principal ("[hidden email]") - in_creds cred's realm is overwritten by one from "sourcename->realm"


this issue is present in Heimdal versions in 1.4.x and 1.5.x. From v.7.0 and up, _gsskrb5_canon_name() has been reworked.
so it is not possible to simply backport changes.


is this normal?  if so, why we need to overwrite it?

regards,
Alibek

[Viktor Dukhovni-2]

> On Aug 10, 2018, at 4:01 PM, Alibek Jorajev <[hidden email]> wrote:
>
> I am using KRB5 API to fetch TGT and then GSS API to generate negotiate tokens.
> (then I add these tokens into HTTP headers when needed). I am using Heimdal v. 1.4.

You really SHOULD NOT be using Heimdal 1.4.  We only support Heimdal 7.x.

--
        Viktor.

[Alibek Jorajev]

hi Viktor!

I would be happy to use latest 7.x.

but the upgrade will take time (it is on the roadmap).

and I need to patch 1.4 for this specific defect.

I have the following options (no question about moving to 7.x, that will be separate effort):

- do not use realm from "source" in this specific scenario (cross-realm)

- remove "source" all together

- try to backport portion of code (if that code is still meaningful for 1.4) from latest 7.x

do you know, why in 1.5.x series, it was needed to use "source" (client principal's realm)?

regards,

Alibek

On Friday, 10 August 2018, 22:17:59 GMT+1, Viktor Dukhovni <[hidden email]> wrote:

> On Aug 10, 2018, at 4:01 PM, Alibek Jorajev <[hidden email]> wrote:
>
> I am using KRB5 API to fetch TGT and then GSS API to generate negotiate tokens.
> (then I add these tokens into HTTP headers when needed). I am using Heimdal v. 1.4.

You really SHOULD NOT be using Heimdal 1.4.  We only support Heimdal 7.x.

--
    Viktor.

[Viktor Dukhovni-2]

> On Aug 13, 2018, at 2:23 AM, Alibek Jorajev <[hidden email]> wrote:
>
> I have the following options (no question about moving to 7.x, that will be separate effort):
> - do not use realm from "source" in this specific scenario (cross-realm)
> - remove "source" all together
> - try to backport portion of code (if that code is still meaningful for 1.4) from latest 7.x
>
> do you know, why in 1.5.x series, it was needed to use "source" (client principal's realm)?

Sorry, can't help you with code that old.  Perhaps someone else can, based on
your original post, if it was sufficiently detailed.

--
        Viktor.

[Alibek Jorajev]

hi everyone,

I am trying to build latest 7.5.0 Heimdal and getting this error:

  CC       libhcrypto_la-evp-cc.lo
  CC       libhcrypto_la-evp-openssl.lo
/Users/ajorajev/work5/depot/dev/gd/msdk/runtime/component/3rdparty/heimdal-7.5.0/src/heimdal-7.5.0/lib/hcrypto/evp-openssl.c:76:10: fatal error: 'openssl/evp.h' file not found
#include <openssl/evp.h>
         ^
1 error generated.
make[2]: *** [libhcrypto_la-evp-openssl.lo] Error 1
make[1]: *** [all-recursive] Error 1

make: *** [all-recursive] Error 1

I ran configure with paths:

--with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include

where SSLROOT is correct path to OpenSSL - this works with Heimdal v.1.4

but it is not working with 7.x

can someone help me if it is quick?

if not, no worries, I will keep working on it around myself.

regards,

Alibek

[Viktor Dukhovni-2]

> On Aug 17, 2018, at 12:06 PM, Alibek Jorajev <[hidden email]> wrote:
>
> I ran configure with paths:
>
> --with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include
>
> where SSLROOT is correct path to OpenSSL - this works with Heimdal v.1.4
> but it is not working with 7.x
>
> can someone help me if it is quick?

It works correctly with 7.x in my builds:

        --with-hcrypto-default-backend=ossl \
        --with-openssl=/opt/openssl/1.1.0

I have not attempted cross-builds.

--
        Viktor.

[Marcin Cieslak-3]

On Fri, 17 Aug 2018, Alibek Jorajev wrote:

> I ran configure with paths:
> --with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include

Alibek, which OpenSSL do you have? Do you have OpenSSL header files in $SSLROOT/include for sure?

This file has been a part of OpenSSL since like forever.

Marcin

[Alibek Jorajev]

hi Marcin,

thanks for looking into this. I have OpenSSL 1.0.2m.

yes, I double checked, evp.h is there. (I also add "ls $GDSSLROOT/include/openssl/"

and visually confirmed that this header file is there.

I am using Xcode7.3.1 - same toolchain which can build 1.4.

Alibek

On Friday, 17 August 2018, 17:24:02 GMT+1, Marcin Cieslak <[hidden email]> wrote:

On Fri, 17 Aug 2018, Alibek Jorajev wrote:

> I ran configure with paths:
> --with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include

Alibek, which OpenSSL do you have? Do you have OpenSSL header files in $SSLROOT/include for sure?

This file has been a part of OpenSSL since like forever.

Marcin

[Alibek Jorajev]

Hi Marcin!

one more question, do I need to run autoreconf?

I am now running this "autoreconf -f -i"

but in the build instructions (Building Heimdal)

Building Heimdal Heimdal

it just mentions "configure"

Now, I am trying to build for local native machine as a first step, so no cross compiling. I decided to go back to basics.

Alibek

On Friday, 17 August 2018, 17:24:02 GMT+1, Marcin Cieslak <[hidden email]> wrote:

On Fri, 17 Aug 2018, Alibek Jorajev wrote:

> I ran configure with paths:
> --with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include

Alibek, which OpenSSL do you have? Do you have OpenSSL header files in $SSLROOT/include for sure?

This file has been a part of OpenSSL since like forever.

Marcin

[Alibek Jorajev]

I have installed openssl using homebrew and pointed it to /usr/local/opt/openssl/lib and /usr/local/opt/openssl/include and now it builds fine for native (MacOS).

just a guess:

I am using " -framework Security" in the LD_FLAGS.... and I have suspicion that

MacOS 10.13.6 does not have OpenSSL.

On Friday, 17 August 2018, 17:24:02 GMT+1, Marcin Cieslak <[hidden email]> wrote:

On Fri, 17 Aug 2018, Alibek Jorajev wrote:

> I ran configure with paths:
> --with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include

Alibek, which OpenSSL do you have? Do you have OpenSSL header files in $SSLROOT/include for sure?

This file has been a part of OpenSSL since like forever.

Marcin

[Alibek Jorajev]

Hi guys !

Heimdal 1.4 used to have "compile_et" error table compiler tool (in usr/bin folder).

after I have built Heimdal v.7.5.0, I do not see this tool anymore.

(but there are error tables in the source code).

is this normal?

regards,

Alibek

[Alibek Jorajev]

I am trying to cross compile (to armv7s platform) and i am getting this:

... ... ...

Making all in roken
perl /Users/ajorajev/work5/depot/dev/gd/msdk/runtime/component/3rdparty/heimdal-7.5.0/src/heimdal-7.5.0/cf/roken-h-process.pl \
    -c ../../include/config.h  \
    -p /Users/ajorajev/work5/depot/dev/gd/msdk/runtime/component/3rdparty/heimdal-7.5.0/src/heimdal-7.5.0/lib/roken/roken.h.in -o roken.h
failed parse: (!defined(HAVE_STRERROR_R)
make[1]: *** [roken.h] Error 25

make: *** [all-recursive] Error 1

..... ....

did anyone came across this error?

I did find that in the previous versions of Heimdal, roken-h-process.pl was patched.

Heimdal - General - x86_64 cross-compile failing on a i686 32 bit system

Heimdal - General - x86_64 cross-compile failing on a i686 32 bit system x86_64 cross-compile failing on a i686 32 bit system. Hi, I came across following issues while trying to cross c...

but I I assume that it was old change and should be already in the newest versions of Heimdal?

regards,

Alibek