Bugzilla – Full Text Bug Listing
|Summary:||VUL-1: CVE-2018-5709: krb5: An issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. There is avariable "dbentry->n_key_data" in kadmin/dbutil/dump.c that can store 16-bitdata but unknowingly the developer has assigned a "u4" va|
|Product:||[Novell Products] SUSE Security Incidents||Reporter:||Marcus Meissner <meissner>|
|Component:||Incidents||Assignee:||Security Team bot <security-team>|
|Status:||RESOLVED INVALID||QA Contact:||Security Team bot <security-team>|
|Priority:||P4 - Low||CC:||abergmann, astieger, david.mulder, meissner, samba-maintainers, scabrero, security-team, smash_bz|
|Found By:||Security Response Team||Services Priority:|
|Marketing QA Status:||---||IT Deployment:||---|
|Bug Depends on:|
Description Marcus Meissner 2018-01-16 16:35:03 UTC
CVE-2018-5709 An issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. There is a variable "dbentry->n_key_data" in kadmin/dbutil/dump.c that can store 16-bit data but unknowingly the developer has assigned a "u4" variable to it, which is for 32-bit data. An attacker can use this vulnerability to affect other artifacts of the database as we know that a Kerberos database dump file contains trusted data. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-5709 https://github.com/poojamnit/Kerberos-V5-1.16-Vulnerabilities/tree/master/Integer%20Overflow
Comment 1 Andreas Stieger 2018-01-17 12:53:45 UTC
Comment 2 Alexander Bergmann 2018-03-14 09:44:07 UTC
So far, there is no upstream fix available.
Comment 6 Marcus Meissner 2019-04-26 15:52:20 UTC
The created dump can at most have MAX_INT (2^31) entries, so reading it in will also have at most 2^31 entries. The reader scans this unsigned, with 2^32 options, where the INT will always fit in. This cannot be exploited.
Comment 7 Marcus Meissner 2019-04-26 15:59:13 UTC
(small correction, it is a int16 value, but as it is written out, parsing it as unsigned int32 will not be a problem either.)
Comment 8 Samuel Cabrero 2019-06-19 15:48:22 UTC
Reassigned to security-team to closing it.
Comment 9 Marcus Meissner 2019-06-26 11:55:39 UTC