Bug 1272016 (CVE-2015-7830)

Summary:	CVE-2015-7830 wireshark: Pcapng file parser crash
Product:	[Other] Security Response	Reporter:	Adam Mariš <amaris>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	carnil, huzaifas, lemenkov, mmilgram, phatina, rvokal
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	wireshark 1.12.8	Doc Type:	Bug Fix
Doc Text:	It was discovered that Wireshark did not properly parse PCAP Next Generation Dump File Format (PCAPNG) files. By tricking an unsuspecting user into opening specially crafted PCAPNG files, An attacker could exploit this flaw to cause a crash or, possibly, execute arbitrary code with the privileges of the user opening the file.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-26 16:46:38 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1272020
Bug Blocks:	1272019

Description Adam Mariš 2015-10-15 09:45:18 UTC

A vulnerability was found in wireshark causing the pcapng parser to crash while copying an interface filter. Attacker could crash wireshark by injecting a malformed packet onto the wire or by convincing someone to read a malformed packet trace file.

Upstream patch:

https://bugs.wireshark.org/bugzilla/attachment.cgi?id=13807&action=diff

External reference:

https://www.wireshark.org/security/wnpa-sec-2015-30.html

Comment 1 Adam Mariš 2015-10-15 09:51:11 UTC

Created wireshark tracking bugs for this issue:

Affects: fedora-all [bug 1272020]

Comment 2 Stefan Cornelius 2015-10-26 16:04:02 UTC

So, the root cause is using the address of an pointer instead of the pointer itself. This can lead to a stack-based memory corruption because the memcpy() copies into the stack space, where the pointer is located. Stack corruptions are problematic, since it may be possible to overwrite a return address or something similar. Since it doesn't overwrite the pointer directly but with an offset of 38h, it may be possible to align the stack in a way that would allow to overwrite something without disrupting, for example, stack canaries. The length of the memcpy() is controllable, too ... so bottom line, I wouldn't rule out code execution.

Comment 4 Kurt Seifried 2015-11-02 19:53:51 UTC

Statement:

This issue affects the versions of wireshark as shipped with Red Hat Enterprise Linux 5, 6 and 7. Red Hat Product Security has rated this issue as having Moderate security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.