Bug 1201792 (CVE-2015-0261)

Summary: CVE-2015-0261 tcpdump: IPv6 mobility printer mobility_opt_print() typecastimg/signedness error
Product: [Other] Security Response Reporter: Martin Prpič <mprpic>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: athmanem, carnil, msekleta, nparmar, thozza
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: tcpdump 4.7.2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-06-01 19:23:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1201799    
Bug Blocks: 1201800, 1415638    

Description Martin Prpič 2015-03-13 14:13:34 UTC
A flaw was found in tcpdump's IPv6 mobility printer. A remote attacker could use this flaw to cause tcpdump to crash, resulting in a denial of service, or possibly execute arbitrary code.

Upstream patch:


Comment 1 Martin Prpič 2015-03-13 14:17:01 UTC
Created tcpdump tracking bugs for this issue:

Affects: fedora-all [bug 1201799]

Comment 2 Stefan Cornelius 2015-03-18 15:02:28 UTC
The root of this problem is a typcasting/signedness issue introduced by the following commit https://github.com/the-tcpdump-group/tcpdump/commit/57c538422b7fcde95be3df88912f13a792ce7ccc

Previously, mobility_opt_print() would handle "len" as "int" (=positive and negative numbers), the commit changed this to "unsigned int" (=only positive numbers).

In order to understand why this caused a problem, we need to look at the buffer length check and loop a bit further down in the function:
>>  for (i = 0; i < len; i += optlen) {
>>     if (bp[i] == IP6MOPT_PAD1)

In the older version, when calling mobility_opt_print() with a negative "len", the "i < len" check would not be satisfied and we would not enter the loop and try to read from bp[i].

In the new version, the previously negative "len" would now be casted to "unsigned int", and will be turned into a (possibly large) positive number instead. Thus, this will mess up the "i < len" check and we incorrectly enter the loop and e.g. try to read from bp[i], where position "i" may now be out of the bounds of "bp".

I guess in most scenarios, this will crash due to the out-of-bounds read. If, however, you manage to somehow get around this, it may be possible to corrupt memory further down the code path - although I have not checked in depth how likely this is.

Comment 4 Fedora Update System 2015-03-30 07:00:55 UTC
tcpdump-4.7.3-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 5 Fedora Update System 2015-03-31 21:44:19 UTC
tcpdump-4.7.3-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Fedora Update System 2015-04-18 09:48:03 UTC
tcpdump-4.5.1-4.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 errata-xmlrpc 2017-08-01 12:14:16 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2017:1871 https://access.redhat.com/errata/RHSA-2017:1871