[39359] in Kerberos
Re: 3 kerberos security issues
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Mar 1 15:39:34 2024
Message-ID: <a53ee311-4d4c-48c8-ae66-f0e90de544c8@mit.edu>
Date: Fri, 1 Mar 2024 15:38:04 -0500
MIME-Version: 1.0
Content-Language: en-US
To: Alexander Bergmann <abergmann@suse.com>, kerberos@mit.edu
From: "Greg Hudson" <ghudson@mit.edu>
In-Reply-To: <20240301121305.s76fxuoesmnupbuw@castor>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: kerberos-bounces@mit.edu
On 3/1/24 07:13, Alexander Bergmann via Kerberos wrote:
> We got notified via NVD about 3 new security issues. Right now there
> seams to be no upstream reference. Could someone please comment on this?
>
> CVE-2024-26458: Memory leak at /krb5/src/lib/rpc/pmap_rmt.c
> CVE-2024-26461: Memory leak at /krb5/src/lib/gssapi/krb5/k5sealv3.c
> CVE-2024-26462: Memory leak at /krb5/src/kdc/ndr.c
These CVEs appear to be the result of someone running a static analysis
tool over the MIT krb5 code base and assigning CVEs to each resulting
defect, without performing any additional impact analysis or upstream
consultation.
The pmap_rmt.c leak only affects pmap_rmtcall(), which is unused by the
rest of the krb5 code base and likely unused by anyone else.
The k5sealv3.c leak affects an encoding function, and happens on a
bounds check which likely cannot be triggered with any choice of
memory-valid API inputs. (The bounds check was itself introduced to
quash a different static analysis defect.)
The ndr.c leak also affects an encoding function, and triggers if the
input contains invalid UTF-8. This one might be triggerable by a
request (though it may require elevated privilege), but I would not have
requested a CVE for it myself.
I will fix these on the mainline, but I only expect to assign a ticket
to the third one.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
