This addresses part of https://github.com/heimdal/heimdal/issues/1214
to audit potential network leaks with [libdefaults] block_dns = yes.
NI_NUMERICHOST is _probably_ sufficient -- we probably won't see many
systems using NIS to look up service names by number if we fail to
specify NI_NUMERICSERV, and such systems probably require careful
auditing of their own. And I don't know of any way NI_NUMERICSCOPE
could trigger network leaks. But named scope ids are such a niche
option with IPv6 that setting it to forestall concerns can't hurt
much, and it makes reviewing easier if we just unconditionally flip
on all the numeric-only options.
This change has two parts:
1. Provide our own local implementation of numeric-only getaddrinfo
in auditdns.c used to audit for DNS leaks, rather than deferring
to dlsym(RTLD_NEXT, "getaddrinfo"), in terms of inet_pton.
To keep review and implementation simple, this is limited to
AI_NUMERICHOST _and_ AI_NUMERICSERV -- this requires that we
arrange to pass AI_NUMERICSERV in callers too.
2. Wherever we implement block_dns, set AI_NUMERICSERV in addition to
AI_NUMERICHOST as needed by the new auditdns.c getaddrinfo.
(In principle this might also avoid other network leaks -- POSIX
guarantees no name resolution service will be invoked, and gives
NIS+ as an example.)
One tiny semantic change to avoid tripping over the auditor:
kadmin(8) now uses the string "749" rather than the string
"kerberos-adm". (Currently we don't audit kadmin(8) for DNS leaks
but let's avoid leaving a rake to step on.) Every other caller I
found is already guaranteed to pass a numeric service rather than
named service to getaddrinfo.
fix https://github.com/heimdal/heimdal/issues/1212
If block_dns is set, call getaddrinfo with AI_NUMERICHOST set and
AI_CANONNAME clear.
Some paths may not have set AI_CANONNAME, but it's easier to audit
this way when the getaddrinfo prelude is uniform across call sites,
and the compiler can optimize it away.
Instead of freeing host->ai on return from submit_request in the
http_proxy path, stash the proxy's ai in another member host->freeai
which will be freed when host is freed.
Assumption: All hosts created in submit_request cease to be used
before any of them are freed, so it's safe to pick one host to hang
the proxy's ai on and free the ai when that host is freed.
fix https://github.com/heimdal/heimdal/issues/1205
If multiple valid CRLs are specified for a particular issuer, only the
first will be checked. The documentation didn’t really hint at this.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Pretty sure it is not useful for applications to be able to write to
this.
However, caveat: this could break programs that expect to pass around
&heimdal_version or &heimdal_long_version to functions that expect
pointers to non-const objects even if they don't modify them.
This changes the public header file but I doubt it was ever intended
that applications could change these by writing to them. (Not sure
why they're not declared as const arrays in any case.)
This is almost certainly intended never to be written to, so let's
let the operating system detect that mistake for us by mapping it in
a .rodata segment mapped read-only that will cause SIGSEGV on write.
fix https://github.com/heimdal/heimdal/issues/1136
This way if anything _does_ write to it, it has the opportunity to be
caught by SIGSEGV, by having zero_ivec in a .rodata segment mapped
read-only.
fix https://github.com/heimdal/heimdal/issues/1135
The struct _krb5_key_type.type is krb5_enctype. Cast it to
krb5_keytype before assigning to the 'krb5_keytype *keytype'
output variable to avoid a warning from Clang 1500 on Darwin.
Excluded: libtomath and libedit files, most of which appear to be
testing or example code not involved in production, and which are
derived from an upstream that should perhaps have patches submitted
upstream instead.
fix https://github.com/heimdal/heimdal/issues/1111
decrypt_internal_derived(), decrypt_internal_enc_then_cksum(),
decrypt_internal(), and decrypt_internal_special() execute the
following pattern where 'p' is an allocation of size 'len'
l = len - n
memmove(p, p + n, l);
result->data = realloc(p, l);
if (result->data == NULL && l != 0) {
free(p);
return krb5_enomem(context);
}
result->length = l;
which when compiled by gcc 13.0.1-0.12.fc38 or gcc-13.0.1-0.13.fc39
generates the following warning
warning: pointer 'p' may be used after 'realloc' [-Wuse-after-free]
The C language specification indicates that it is only safe to free()
the pointer passed to realloc() if errno is set to ENOMEM. Yet the
warning is generated by the following pattern
l = len - n
memmove(p, p + n, l);
errno = 0;
result->data = realloc(p, l);
if (result->data == NULL && l != 0) {
if (errno == ENOMEM)
free(p);
return krb5_enomem(context);
}
result->length = l;
The value of performing the realloc() is questionable. realloc()
in many cases will need to perform a second allocation of the
smaller size and then perform a memcpy() which will slow down
the operation without saving much memory. The allocation is already
very small.
This change avoids the warning by removing the realloc() entirely.
