| Summary: | nasm new security issues fixed upstream in 2.14.02 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | normal | ||
| Priority: | Normal | CC: | andrewsfarm, davidwhodgins, geiger.david68210, sysadmin-bugs, tarazed25 |
| Version: | 7 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA7-64-OK MGA7-32-OK | ||
| Source RPM: | nasm-2.13.03-2.mga7.src.rpm | CVE: | |
| Status comment: | |||
|
Description
David Walser
2020-07-07 23:18:46 CEST
Advisory: ======================== Updated nasm packages fix security vulnerabilities: Netwide Assembler (NASM) 2.13 has a stack-based buffer over-read in the disasm function of the disasm/disasm.c file. Remote attackers could leverage this vulnerability to cause a denial of service or possibly have unspecified other impact via a crafted ELF file (CVE-2018-10254). Netwide Assembler (NASM) 2.14rc0 has an endless while loop in the assemble_file function of asm/nasm.c because of a globallineno integer overflow (CVE-2018-10316). Netwide Assembler (NASM) 2.14rc15 has a buffer over-read in x86/regflags.c (CVE-2018-16382). NASM nasm-2.13.03 nasm- 2.14rc15 version 2.14rc15 and earlier contains a memory corruption (crashed) of nasm when handling a crafted file due to function assemble_file(inname, depend_ptr) at asm/nasm.c:482. vulnerability in function assemble_file(inname, depend_ptr) at asm/nasm.c:482. that can result in aborting/crash nasm program. This attack appear to be exploitable via a specially crafted asm file (CVE-2018-1000667). asm/labels.c in Netwide Assembler (NASM) is prone to NULL Pointer Dereference, which allows the attacker to cause a denial of service via a crafted file (CVE-2018-16517). Netwide Assembler (NASM) 2.14rc15 has an invalid memory write (segmentation fault) in expand_smacro in preproc.c, which allows attackers to cause a denial of service via a crafted input file (CVE-2018-16999). Netwide Assembler (NASM) 2.14rc16 has a heap-based buffer over-read in expand_mmac_params in asm/preproc.c for the special cases of the % and $ and ! characters (CVE-2018-19215). Netwide Assembler (NASM) 2.14rc15 has a heap-based buffer over-read in expand_mmac_params in asm/preproc.c for insufficient input (CVE-2018-19214). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10016 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10254 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10316 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16382 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16517 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16999 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19214 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19215 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000667 https://lists.suse.com/pipermail/sle-security-updates/2020-July/007073.html ======================== Updated packages in core/updates_testing: ======================== nasm-2.14.02-1.mga7 nasm-doc-2.14.02-1.mga7 nasm-rdoff-2.14.02-1.mga7 from nasm-2.14.02-1.mga7.src.rpm Assignee:
bugsquad =>
qa-bugs MGA7, x86_64
Updated the three packages.
Used a set of test programs, both C and assembler, which have a makefile.
$ make clean
$ make all
This compiles both sets and runs the executables.
$ ls pack
call1_64.asm fltarith_64.asm intarith_64.c printf2_64.c
call1_64.c fltarith_64.c intlogic_64.asm shift_64.asm
call1_64.h hello_64.asm loopint_64.c stringlength.asm
fib_64l.asm hello.asm loopint.asm test_call1_64.c
fib_64m.asm hello.c Makefile testreg_64.asm
fib64m.asm horner_64.asm printf1_64.asm
fib.c ifint_64.asm printf1_64.c
fibonacci.c intarith_64.asm printf2_64.asm
Start of Makefile:
# Makefile_64 for nasm assembly code (and corresponding C code)
# for 64-bit operating systems with 64-bit gcc and nasm
# on your system -m64 may be optional on gcc to use 8GB of ram
all: hello_64.out printf1_64.out printf2_64.out \
intarith_64.out fltarith_64.out fib_64l.out fib_64m.out
hello_64.out: hello_64.asm
nasm -f elf64 -l hello_64.lst hello_64.asm
gcc -m64 -o hello_64 hello_64.o
./hello_64 > hello_64.out
cat hello_64.out
gcc -m64 hello.c
./a.out > hello.outc
rm -f a.out
Sample output:
$ make all
nasm -f elf64 -l hello_64.lst hello_64.asm
gcc -m64 -o hello_64 hello_64.o
./hello_64 > hello_64.out
cat hello_64.out
Hello world
gcc -m64 hello.c
./a.out > hello.outc
rm -f a.out
nasm -f elf64 -l printf1_64.lst printf1_64.asm
gcc -m64 -o printf1_64 printf1_64.o
./printf1_64 > printf1_64.out
cat printf1_64.out
a=5, rax=7
gcc -m64 printf1_64.c
./a.out > printf1_64.outc
rm -f a.out
nasm -f elf64 -l printf2_64.lst printf2_64.asm
gcc -m64 -o printf2_64 printf2_64.o
./printf2_64 > printf2_64.out
cat printf2_64.out
printf2: flt2=-1.234568e+302
char1=a, str1=mystring, len=9
char1=a, str1=mystring, len=9, inta1=12345678, inta2=12345678900
hex1=123456789ABCD, flt1=5.327000e-30, flt2=-1.234568e+302
gcc -m64 printf2_64.c
./a.out > printf2_64.outc
rm -f a.out
nasm -f elf64 -l intarith_64.lst intarith_64.asm
gcc -m64 -o intarith_64 intarith_64.o
./intarith_64 > intarith_64.out
cat intarith_64.out
c=5 , a=3, b=4, c=5
c=a+b, a=3, b=4, c=7
c=a-b, a=3, b=4, c=-1
c=a*b, a=3, b=4, c=12
c=c/a, a=3, b=4, c=4
gcc -m64 intarith_64.c
./a.out > intarith_64.outc
rm -f a.out
nasm -f elf64 -l fltarith_64.lst fltarith_64.asm
gcc -m64 -o fltarith_64 fltarith_64.o
./fltarith_64 > fltarith_64.out
cat fltarith_64.out
c=5.0, a=3.000000e+00, b=4.000000e+00, c=5.000000e+00
c=a+b, a=3.000000e+00, b=4.000000e+00, c=7.000000e+00
c=a-b, a=3.000000e+00, b=4.000000e+00, c=-1.000000e+00
c=a*b, a=3.000000e+00, b=4.000000e+00, c=1.200000e+01
c=c/a, a=3.000000e+00, b=4.000000e+00, c=4.000000e+00
a=i , a=8.000000e+00, b=1.600000e+01, c=1.600000e+01
a<=b , a=8.000000e+00, b=1.600000e+01, c=1.600000e+01
b==c , a=8.000000e+00, b=1.600000e+01, c=1.600000e+01
gcc -m64 fltarith_64.c
./a.out > fltarith_64.outc
rm -f a.out
nasm -f elf64 -l fib_64l.lst fib_64l.asm
gcc -m64 -o fib_64l fib_64l.o
./fib_64l > fib_64l.out
cat fib_64l.out
fibonacci numbers
1
2
3
5
8
13
......
As far as I can tell this all looks fine.
There is an i586 pack as well which will be tested if there is a 32-bit VM available.
Not familiar with nasm-rdoff.
Some information at https://www.mankier.com/package/nasm-rdoff.
ldrdf link RDOFF objects and libraries produced by rdflib(1)
rdf2bin convert an RDOFF object file to flat binary
rdf2com alias for rdf2bin
rdf2ihx alias for rdf2bin
rdf2ith alias for rdf2bin
rdf2srec alias for rdf2bin
rdfdump dumps an RDOFF object in human-readable form
rdflib manage a library file for use with ldrdf(1)
rdx load and execute an RDOFF object
The utilities are all there.
$ ls /usr/bin/rdf2*
/usr/bin/rdf2bin* /usr/bin/rdf2ihx@ /usr/bin/rdf2srec@
/usr/bin/rdf2com@ /usr/bin/rdf2ith@
$ which rdfdump rdflib rdx
/usr/bin/rdfdump
/usr/bin/rdflib
/usr/bin/rdx
The CVEs were not followed up before updating but that can be redressed. However, looking at the first one I do not understand how to test the PoC file. Upstream run nasm with gdb and offers poc_divide as the input.
I tried
$ nasm -f elf64 poc_divide
but could make no sense of the error output. The file itself looks very strange:
$ cat poc_divide
;nit
Uit thaxax-F-----P-7*-(-c"-chx-
UidUit
Uit tbi
Litbi
ALiGn "
chaxax-F-----P-7*-(-c"-chx7*-(-chx/F-!-p
rrr�rrrrrrrrrrr$�itUit
Uit thaxax-F-----P-7*-(-c"-chx-
UidUit
Uit tbi
Litbi
ALiGn "
chaxax-F-----P-7*-(-c"-chx7*-(-chx/F-!-p
rrr�rrrrrrrrrrr$�it�ax
which looks like random garbage, so there is little point in pursuing this.
OK for 64-bits anyway.CC:
(none) =>
tarazed25 The Mime type for the PoC file is application/octet-stream and 'file' describes it as data.
Len Lawrence
2020-07-09 00:41:26 CEST
Whiteboard:
(none) =>
MGA7-64-OK Booted a 32-bit virtualbox and made sure mga7 was up-to-date. Installed the nasm packages from core and tested the i586 pack of test files which were distributed alongside the 64-bit ones. Ran 'make clean', 'make all'. Results similar to the earlier 64-bit ones. Installed the three packages from updates testing and ran the suite again. All assembler modules compiled to their respective object files and the corresponding C files linked to them successfully and produced the same output as before. e.g. nasm -f elf -l fltarith.lst fltarith.asm gcc -o fltarith fltarith.o ./fltarith c=5.0, a=3.333333e+00, b=4.444444e+00, c=5.000000e+00 c=a+b, a=3.333333e+00, b=4.444444e+00, c=7.777778e+00 c=a-b, a=3.333333e+00, b=4.444444e+00, c=-1.111111e+00 c=a*b, a=3.333333e+00, b=4.444444e+00, c=1.481481e+01 c=c/a, a=3.333333e+00, b=4.444444e+00, c=4.444444e+00 gcc fltarith.c ./a.out c=5.0, a=3.000000e+00, b=4.000000e+00, c=5.000000e+00 c=a+b, a=3.000000e+00, b=4.000000e+00, c=7.000000e+00 c=a-b, a=3.000000e+00, b=4.000000e+00, c=-1.000000e+00 c=a*b, a=3.000000e+00, b=4.000000e+00, c=1.200000e+01 c=c/a, a=3.000000e+00, b=4.000000e+00, c=4.000000e+00 rm -f a.out [lcl@talitha i586]$ ls compile hello* intarith* Makefile printf1.lst printf2.o fltarith* hello32 intarith.asm nasm32/ printf1.o fltarith.asm hello_32.asm intarith.c nasm32.tar.xz printf2* fltarith.c hello.asm intarith.lst printf1* printf2.asm fltarith.lst hello.lst intarith.o printf1.asm printf2.c fltarith.o hello.o link printf1.c printf2.lst Passing this for 32-bits. Whiteboard:
MGA7-64-OK =>
MGA7-64-OK MGA7-32-OK Validating. Advisory in Comment 2. Keywords:
(none) =>
validated_update openSUSE has issued an advisory for this on July 13: https://lists.opensuse.org/opensuse-security-announce/2020-07/msg00015.html
Dave Hodgins
2020-07-31 11:35:14 CEST
Keywords:
(none) =>
advisory An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0303.html Status:
NEW =>
RESOLVED |