Summary: | truncated messages ending with boolean can over-read up to 3 bytes | ||
---|---|---|---|
Product: | dbus | Reporter: | Simon McVittie <smcv> |
Component: | core | Assignee: | Simon McVittie <smcv> |
Status: | RESOLVED FIXED | QA Contact: | D-Bus Maintainers <dbus> |
Severity: | normal | ||
Priority: | medium | CC: | bugzilla, thiago |
Version: | git master | Keywords: | patch |
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | review+ | ||
i915 platform: | i915 features: | ||
Attachments: | validate_body_helper: Bounds-check before validating booleans |
Description
Simon McVittie
2018-07-23 10:28:58 UTC
This bug was introduced in early 2005 (62e46533 "hardcode dbus_bool_t to 32 bits") so all supported dbus versions are affected. I'll also need reviews on Bug #107349 and Bug #107350 before I can actually release this fix. Comment on attachment 140779 [details] [review] validate_body_helper: Bounds-check before validating booleans Review of attachment 140779 [details] [review]: ----------------------------------------------------------------- Looks good to me. Ship it. (In reply to Thiago Macieira from comment #3) > Looks good to me. Ship it. Do you agree with my assessment that this is probably not a practical security vulnerability, or do you think we need to do the embargo/CVE thing? Comment on attachment 140779 [details] [review] validate_body_helper: Bounds-check before validating booleans Review of attachment 140779 [details] [review]: ----------------------------------------------------------------- r+ I can’t think of an easy way to exploit this, unless there’s a way for the attacker to guarantee that the heap allocation for their crafted message is over the top of some previously-freed memory which they care about getting some bytes from. Maybe we should explicitly zero the allocation of an incoming message before doing anything about parsing that message, as paranoia? That would only guard against bugs of this class found in future releases though. Making this public since we have concluded that it isn't a security flaw. Fixed in git for 1.12.0, 1.13.6 and 1.10.28, thanks |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.