Bug 1626256 (CVE-2018-1000667)

Summary:	CVE-2018-1000667 nasm: Memory corruption in assemble_file() function in asm/nasm.c:482
Product:	[Other] Security Response	Reporter:	Pedro Sampaio <psampaio>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	java-sig-commits, mizdebsk, nickc
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-25 22:16:14 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:	1626257, 1626258, 1633758
Bug Blocks:	1626259

Description Pedro Sampaio 2018-09-06 21:15:37 UTC

NASM 2.10.07 through 2.13.03, and potentially earlier, contains a denial of service vulnerability that can result in a segmentation fault due to the program incorrectly dereferencing an invalid address. This attack is exploitable via a specially crafted asm file.

Upstream bug:

https://bugzilla.nasm.us/show_bug.cgi?id=3392507

References:

https://github.com/cyrillos/nasm/issues/3

Comment 1 Pedro Sampaio 2018-09-06 21:16:01 UTC

Created nasm tracking bugs for this issue:

Affects: fedora-all [bug 1626257]

Comment 3 Scott Gayou 2018-09-26 19:56:31 UTC

Posted analysis upstream, copying here. In summary, found a new, very similar crash.

This appears to be due to the following pattern in preproc.c:

```c
tt = tokenize(tline->text);
tt = expand_smacro(tt);
size = parse_size(tt->text);
```

In this case, expand_smacro errors out. ->text is set to NULL, and -> type is set to TOK_WHITESPACE. We then call parse_size with NULL. No NULL checks occur inside, and we eventually crash when trying to dereference null inside of bsii's stricmp call.

This same pattern also appears in the case of PP_ARG. Thus, we can create a similar reproducer via crafting a file with %arg instead of %local. Both reproducers are attached (I have drastically reduced the reproducers to the minimal crash case I believe).