Bug 1242481

Summary:	file-roller: denial of service while processing crafted .zip file
Product:	[Other] Security Response	Reporter:	Vasyl Kaigorodov <vkaigoro>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	dking, marinaz, mclasen
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-08-04 08:46:20 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:	1242486
Bug Blocks:	1242485

Description Vasyl Kaigorodov 2015-07-13 12:14:43 UTC

It was reported that file-roller will start eating CPU and the application will freeze if a crafted .zip file opened.
Upstream bug report:
https://bugzilla.gnome.org/show_bug.cgi?id=752245

There's not fix available yet.

Comment 1 Vasyl Kaigorodov 2015-07-13 12:19:02 UTC

Created file-roller tracking bugs for this issue:

Affects: fedora-all [bug 1242486]

Comment 2 Stefan Cornelius 2015-07-15 14:58:03 UTC

This has changed throughout versions.

RHEL6:
There's something that can become similar to an invinite loop in get_alternative_uri() function (the while loop).

Apparently fixed via
https://git.gnome.org/browse/file-roller/commit/src/file-utils.c?id=34b64f3a897c4b4e8e180c028f326bc921eb08ec

RHEL7: This only crashed the very first time for me.
It was a NULL-pointer dereference in fr_archive_create(): archive can be NULL after the call to create_archive_for_mime_type(), but this condition is never checked.

> archive = create_archive_for_mime_type (archive_type,
> 						file,
> 						mime_type,
>						FR_ARCHIVE_CAN_WRITE);
>
>	parent = g_file_get_parent (file);
>	archive->priv->have_write_permissions = _g_file_check_permissions
> (parent, W_OK);

Introduced via: https://git.gnome.org/browse/file-roller/commit/src/fr-archive.c?id=4b64c5ece7a4e209799b72845b1587d4b9323940


Fedora: It seems like the RHEL7 flaw is still in the code. But there's a new option to handle zips using libarchive, which probably hides the problem.

Comment 3 Stefan Cornelius 2015-08-04 08:44:28 UTC

A zip file with a folder named "#" inside it can crash the file-roller utility. There is no indication that code execution is possible, so this should be limited to a crash only.

If you encounter a crash and suspect that a "#" folder inside the zip file may be the culprit, refrain from opening the file again in file-roller. You can alternatively try to unpack the zip file using other zip decompression utilities.