Bug 1076229 (CVE-2018-5709)

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: IncidentsAssignee: Security Team bot <security-team>
Status: RESOLVED INVALID QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P4 - Low CC: abergmann, astieger, david.mulder, meissner, samba-maintainers, scabrero, security-team, smash_bz
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://smash.suse.de/issue/198323/
Whiteboard: CVSSv3:SUSE:CVE-2018-5709:5.3:(AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) maint:planned:update
Found By: Security Response Team Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Bug Depends on:    
Bug Blocks: 1132051    

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 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 
closing