SUSE has issued an advisory on July 6: https://lists.suse.com/pipermail/sle-security-updates/2020-July/007073.html It looks like these ones affect us: CVE-2018-10016 CVE-2018-10254 CVE-2018-10316 CVE-2018-16382 CVE-2018-1000667 CVE-2018-16517 CVE-2018-16999 CVE-2018-19214 CVE-2018-19215 and these don't: CVE-2018-19216 CVE-2018-8881 CVE-2018-8882 CVE-2018-8883
Done for mga7!
CC: (none) => geiger.david68210
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.
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_updateCC: (none) => andrewsfarm, sysadmin-bugs
openSUSE has issued an advisory for this on July 13: https://lists.opensuse.org/opensuse-security-announce/2020-07/msg00015.html
Keywords: (none) => advisoryCC: (none) => davidwhodgins
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0303.html
Status: NEW => RESOLVEDResolution: (none) => FIXED