Groups | Search | Server Info | Login | Register
Groups > comp.protocols.kerberos > #5260
| From | "Greg Hudson" <ghudson@mit.edu> |
|---|---|
| Newsgroups | comp.protocols.kerberos |
| Subject | Re: 3 kerberos security issues |
| Date | 2024-03-01 15:38 -0500 |
| Organization | TNet Consulting |
| Message-ID | <mailman.32.1709325491.2322.kerberos@mit.edu> (permalink) |
| References | <20240301121305.s76fxuoesmnupbuw@castor> <a53ee311-4d4c-48c8-ae66-f0e90de544c8@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.
Back to comp.protocols.kerberos | Previous | Next | Find similar
Re: 3 kerberos security issues "Greg Hudson" <ghudson@mit.edu> - 2024-03-01 15:38 -0500
csiph-web