Skip Menu |
 

This queue is for tickets about the GSSAPI CPAN distribution.

Report information
The Basics
Id: 121873
Status: new
Priority: 0/
Queue: GSSAPI

People
Owner: Nobody in particular
Requestors: ioanr [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.28
Fixed in: (no value)

Attachments
0001-Trying-to-release-mech_type-OID-from-gss_accept_sec_.patch



Subject: SIGABRT caused when calling gss_release_oid for an OID that should not be released
Hi,

This is with MIT krb5 1.14.4 on Fedora 25 and 1.14.1 on CentOS7.3.
 
When passing a scalar for the `mech_type` argument to `GSSAPI::Context::accept`,
an OID is created. When this goes out of scope, `gss_release_oid` is called,
which causes an ABRT in `generic_gss_release_oid` from libgssapi_krb5.so.2.
 
 
```
mech_type The returned OID value will be a pointer
          into static storage, and should be treated as
          read-only by the caller (in particular, it does
          not need to be freed).
```
 
I don't see any way to know which OIDs need to be freed just from their
properties, so the simplest solution seems to be to just not call
`gss_release_oid`. MIT appears to be the only implementation that has
`gss_release_oid`. It is also not part of the RFC.

I've attached a small patch which does that, but I assume this will cause memory
leaks for some people and needs to be tested.

Thanks
Subject: 0001-Trying-to-release-mech_type-OID-from-gss_accept_sec_.patch
From 595335a269a78eb3ee12ddb285aa6eb759e127b1 Mon Sep 17 00:00:00 2001 From: Ioan Rogers <ioan.rogers@sophos.com> Date: Wed, 24 May 2017 12:22:25 -0700 Subject: [PATCH] Trying to release mech_type OID from gss_accept_sec_context causes SIGABRT This is with MIT krb5 1.14.4. When passing a scalar for the `mech_type` argument to `GSSAPI::Context::accept`, an OID is created. When this goes out of scope, `gss_release_oid` is called, which causes an ABRT in `generic_gss_release_oid` from libgssapi_krb5.so.2. From https://tools.ietf.org/html/rfc2744 (abbreviated): ``` mech_type The returned OID value will be a pointer into static storage, and should be treated as read-only by the caller (in particular, it does not need to be freed). ``` I don't see any way to know which OIDs need to be freed just from their properties, so the simplest solution seems to be to just not call `gss_release_oid`. MIT appears to be the only implementation that has `gss_release_oid`. It is also not part of the RFC. `gss_release_oid` also performs the flag checks removed here. --- xs/OID.xs | 21 --------------------- 1 file changed, 21 deletions(-) diff --git a/xs/OID.xs b/xs/OID.xs index c805e45..11f4d11 100644 --- a/xs/OID.xs +++ b/xs/OID.xs @@ -7,27 +7,6 @@ new(class) OUTPUT: RETVAL -void -DESTROY(oid) - GSSAPI::OID oid - PREINIT: - OM_uint32 minor; - PPCODE: -#if !defined(HEIMDAL) - if (oid != NULL && - oid != __KRB5_MECHTYPE_OID && - oid != __KRB5_OLD_MECHTYPE_OID && - oid != __GSS_KRB5_NT_USER_NAME && - oid != __GSS_KRB5_NT_PRINCIPAL_NAME && - oid != __SPNEGO_MECHTYPE_OID && - oid != __gss_mech_krb5_v2 ) { - (void)gss_release_oid(&minor, &oid); - } -#endif -#if defined(HEIMDAL) -# warn("gss_release_oid is unsupported and not Part of the API!"); -#endif - GSSAPI::Status from_str(class, oid, str) char * class -- 2.9.4


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.