Bug 22388 - Update request: nasm-2.13.03 (fixes CVE-2017-1781[0-9] and CVE-2017-17820)
Summary: Update request: nasm-2.13.03 (fixes CVE-2017-1781[0-9] and CVE-2017-17820)
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA6-64-OK MGA6-32-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2018-01-13 21:40 CET by Stig-Ørjan Smelror
Modified: 2018-02-17 13:20 CET (History)
3 users (show)

See Also:
Source RPM: nasm-2.12.02-2.mga7
CVE:
Status comment: Fixed upstream in 2.13.02


Attachments
nasm-2.13.02 patch (2.27 KB, patch)
2018-01-13 21:40 CET, Stig-Ørjan Smelror
Details | Diff
Updated patch for nasm 2.13.02 (1.96 KB, patch)
2018-01-14 07:20 CET, Stig-Ørjan Smelror
Details | Diff
Switch font for nasmdoc patch (2.30 KB, patch)
2018-01-14 07:21 CET, Stig-Ørjan Smelror
Details | Diff
Makefile and sample 32-bit programs (3.70 KB, application/octet-stream)
2018-02-15 23:35 CET, Len Lawrence
Details

Description Stig-Ørjan Smelror 2018-01-13 21:40:13 CET
Hi.

I decided to look into upgrading the x264 package, but it needs nasm-2.13 so I hacked it together and made sure it worked locally and compiled fine in mock.

Also had to patch their psfonts.ph file to use a different font.

See attached svn diff patch.

Cheers,
Stig
Comment 1 Stig-Ørjan Smelror 2018-01-13 21:40:47 CET
Created attachment 9896 [details]
nasm-2.13.02 patch
Comment 2 Thomas Backlund 2018-01-14 00:13:15 CET
A couple of comments...
- first off, if a patch is merged/obsolete, dont comment it out with a #, just remove them.
- same goes for changes in filelists and and other stuff removed upstream, dont comment it, just remove it... that's why we use a VCS ...

Also, you didn't attach your new patch
Comment 3 Stig-Ørjan Smelror 2018-01-14 07:19:41 CET
Good morning.

Thanks for the corrections. I commented them out because the package is yours and wanted you to see what was done.

If it's OK with you, can I commit these changes to SVN?

Or do you want another patch?

Thanks.

Cheers,
Stig
Comment 4 Stig-Ørjan Smelror 2018-01-14 07:20:59 CET
Created attachment 9897 [details]
Updated patch for nasm 2.13.02
Comment 5 Stig-Ørjan Smelror 2018-01-14 07:21:37 CET
Created attachment 9898 [details]
Switch font for nasmdoc patch
Comment 6 David Walser 2018-01-17 03:39:51 CET
Fedora has issued an advisory today (January 16):
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/YYKNGOT2RJPJMYLAHG6PJXH5QXLSTVMY/

Updating to this version fixed several security issues.

Mageia 5 and Mageia 6 are also affected.

Component: RPM Packages => Security
Summary: Update request: nasm-2.13.02 => Update request: nasm-2.13.02 (fixes CVE-2017-1781[0-9] and CVE-2017-17820)
QA Contact: (none) => security
Whiteboard: (none) => MGA6TOO

David Walser 2018-02-02 18:29:53 CET

Status comment: (none) => Fixed upstream in 2.13.02

Comment 7 Stig-Ørjan Smelror 2018-02-08 17:36:41 CET
Advisory:
========================

Security fixes for CVE-2017-17810 CVE-2017-17811 CVE-2017-17812 CVE-2017-17813 CVE-2017-17814 CVE-2017-17815 CVE-2017-17816 CVE-2017-17817 CVE-2017-17818 CVE-2017-17819 CVE-2017-17820

In Netwide Assembler (NASM) 2.14rc0, there is a "SEGV on unknown address" that will cause a remote denial of service attack, because asm/preproc.c mishandles macro calls that have the wrong number of arguments.

In Netwide Assembler (NASM) 2.14rc0, there is a heap-based buffer overflow that will cause a remote denial of service attack, related to a strcpy in paste_tokens in asm/preproc.c, a similar issue to CVE-2017-11111.

In Netwide Assembler (NASM) 2.14rc0, there is a heap-based buffer over-read in the function detoken() in asm/preproc.c that will cause a remote denial of service attack.

In Netwide Assembler (NASM) 2.14rc0, there is a use-after-free in the pp_list_one_macro function in asm/preproc.c that will cause a remote denial of service attack, related to mishandling of line-syntax errors.

In Netwide Assembler (NASM) 2.14rc0, there is a use-after-free in do_directive in asm/preproc.c that will cause a remote denial of service attack.

In Netwide Assembler (NASM) 2.14rc0, there is an illegal address access in is_mmacro() in asm/preproc.c that will cause a remote denial of service attack, because of a missing check for the relationship between minimum and maximum parameter counts.

In Netwide Assembler (NASM) 2.14rc0, there is a use-after-free in pp_getline in asm/preproc.c that will cause a remote denial of service attack.

In Netwide Assembler (NASM) 2.14rc0, there is a use-after-free in pp_verror in asm/preproc.c that will cause a remote denial of service attack.

In Netwide Assembler (NASM) 2.14rc0, there is a heap-based buffer over-read that will cause a remote denial of service attack, related to a while loop in paste_tokens in asm/preproc.c.

In Netwide Assembler (NASM) 2.14rc0, there is an illegal address access in the function find_cc() in asm/preproc.c that will cause a remote denial of service attack, because pointers associated with skip_white_ calls are not validated.

In Netwide Assembler (NASM) 2.14rc0, there is a use-after-free in pp_list_one_macro in asm/preproc.c that will lead to a remote denial of service attack, related to mishandling of operand-type errors.

References:
https://nvd.nist.gov/vuln/detail/CVE-2017-17810
https://nvd.nist.gov/vuln/detail/CVE-2017-17811
https://nvd.nist.gov/vuln/detail/CVE-2017-17812
https://nvd.nist.gov/vuln/detail/CVE-2017-17813
https://nvd.nist.gov/vuln/detail/CVE-2017-17814
https://nvd.nist.gov/vuln/detail/CVE-2017-17815
https://nvd.nist.gov/vuln/detail/CVE-2017-17816
https://nvd.nist.gov/vuln/detail/CVE-2017-17817
https://nvd.nist.gov/vuln/detail/CVE-2017-17818
https://nvd.nist.gov/vuln/detail/CVE-2017-17819
https://nvd.nist.gov/vuln/detail/CVE-2017-17820
https://bugzilla.nasm.us/show_bug.cgi?id=3392431
https://bugzilla.nasm.us/show_bug.cgi?id=3392432
https://bugzilla.nasm.us/show_bug.cgi?id=3392424
https://bugzilla.nasm.us/show_bug.cgi?id=3392429
https://bugzilla.nasm.us/show_bug.cgi?id=3392430
https://bugzilla.nasm.us/show_bug.cgi?id=3392436
https://bugzilla.nasm.us/show_bug.cgi?id=3392426
https://bugzilla.nasm.us/show_bug.cgi?id=3392427
https://bugzilla.nasm.us/show_bug.cgi?id=3392428
https://bugzilla.nasm.us/show_bug.cgi?id=3392435
https://bugzilla.nasm.us/show_bug.cgi?id=3392433
========================

Updated packages in core/updates_testing:
========================
nasm-2.13.03-1.mga6
nasm-doc-2.13.03-1.mga6
nasm-rdoff-2.13.03-1.mga6
nasm-debugsource-2.13.03-1.mga6
nasm-debuginfo-2.13.03-1.mga6
nasm-rdoff-debuginfo-2.13.03-1.mga6

from nasm-2.13.03-1.mga6.src.rpm
Stig-Ørjan Smelror 2018-02-08 17:37:05 CET

Assignee: tmb => qa-bugs

Stig-Ørjan Smelror 2018-02-08 17:38:12 CET

Summary: Update request: nasm-2.13.02 (fixes CVE-2017-1781[0-9] and CVE-2017-17820) => Update request: nasm-2.13.03 (fixes CVE-2017-1781[0-9] and CVE-2017-17820)

Stig-Ørjan Smelror 2018-02-08 17:44:56 CET

Version: Cauldron => 6
Whiteboard: MGA6TOO => (none)

Comment 8 Len Lawrence 2018-02-09 03:03:05 CET
Have made a start on this and run one POC test before the update and reproduced the published output, also with gdb.

POC testing.
CVE-2017-17810
https://bugzilla.nasm.us/show_bug.cgi?id=3392431

For functionality testing:
Sample programs at https://www.csee.umbc.edu/portal/help/nasm/sample_64.shtml
See also https://en.wikibooks.org/wiki/X86_Assembly/NASM_Syntax

CC: (none) => tarazed25

Comment 9 Len Lawrence 2018-02-09 11:15:38 CET
Mageia 6 :: x86_64
---------------------------------------------------------------------------

Before updates:

Could not find nasm-debugsource or nasm-rdoff-debuginfo even after enabling various debug repositories and running MageiaUpdate.
Avoided gdb tests after the first one because of lack of knowledge of how the testing framework is implemented and because I suspect that they would not tell us much.

The tests were all of the form:
$ nasm -f bin POC* -o tmp
and produced a list of errors sometimes ending in segfault.  The listings were very similar to those published upstream but did not always terminate in the same way.  There were aborts and more segfaults in the upstream tests.

CVE-2017-17810
https://bugzilla.nasm.us/show_bug.cgi?id=3392431
$ nasm -f bin POC11 -o tmp
GNU debugger test:
$ gdb nasm
..............
Reading symbols from nasm...Reading symbols from /usr/lib/debug/usr/bin/nasm.debug...done.
(gdb) set args -f bin POC11 -o tmp
(gdb) r
Starting program: ........
...............
Program received signal SIGSEGV, Segmentation fault.
expand_smacro (tline=0x7ffff7fd8e30, tline@entry=0x7ffff7fd9890)
    at preproc.c:4340
4340	                                pt = *ptail = new_Token(tline, ttt->type,
(gdb) quit

---------------------------------------------------------------------------

After updates:

CVE-2017-17810
https://bugzilla.nasm.us/show_bug.cgi?id=3392431
$ nasm -f bin POC11 -o tmp
No segmentation fault.

CVE-2017-17811
https://bugzilla.nasm.us/show_bug.cgi?id=3392432
$ nasm -f bin POC12 -o tmp
No apparent change - no abort

CVE-2017-17812
https://bugzilla.nasm.us/show_bug.cgi?id=3392424
$ nasm -f bin POC4 -o tmp
Finished tidily - no segfault.

CVE-2017-17813
https://bugzilla.nasm.us/show_bug.cgi?id=3392429
$ nasm -f bin POC9 -o tmp
Looked the same as before - panic message - no segfault.

CVE-2017-17814
https://bugzilla.nasm.us/show_bug.cgi?id=3392430
$ nasm -f bin POC10 -o tmp
No change and no segfault.

CVE-2017-17815
https://bugzilla.nasm.us/show_bug.cgi?id=3392436
$ nasm -f bin POC15 -o tmp
No change and no segfault.

CVE-2017-17816
https://bugzilla.nasm.us/show_bug.cgi?id=3392426
$ nasm -f bin POC6 -o tmp
Handled quietly after similar diagnostic messages.

CVE-2017-17817
https://bugzilla.nasm.us/show_bug.cgi?id=3392427
$ nasm -f bin POC7 -o tmp
No change - no abort.

CVE-2017-17818
https://bugzilla.nasm.us/show_bug.cgi?id=3392428
$ nasm -f bin POC8 -o tmp
No segfault.

CVE-2017-17819
https://bugzilla.nasm.us/show_bug.cgi?id=3392435
$ nasm -f bin POC14 -o tmp
No segfault.

CVE-2017-17820
https://bugzilla.nasm.us/show_bug.cgi?id=3392433
$ nasm -f bin POC13 -o tmp
No segfault

Summarizing, the diagnostics and behaviour before the updates differed somewhat from the upstream tests; fewer segfaults and no explicit aborts at our end.
After the updates all tests finished tidily and the tmp file was not created during any of the afterwards tests.

Difficult to make a pronouncement on this but my impression is that nasm is safe to use.

Functionality tests later.
Comment 10 Len Lawrence 2018-02-09 11:23:26 CET
I see that the output from POC11 tests went missing.

After the update the gdb test shows that the segfault has been squashed.

(gdb) set args -f bin POC11 -o tmp
(gdb) r
Starting program: /usr/bin/nasm -f bin POC11 -o tmp
...................
POC11:97: error: label or instruction expected at start of line
POC11:98: error: `%%top': not in a macro call
POC11:98: error: macro call expects terminating `)'
POC11:98: error: macro call expects terminating `)'
POC11:98: fatal: macro `%$strucname' expects 5 args
[Inferior 1 (process 32534) exited with code 01]
Comment 11 Len Lawrence 2018-02-09 13:22:35 CET
$ rpm -qa | grep nasm
nasm-2.13.03-1.mga6
nasm-rdoff-2.13.03-1.mga6
nasm-doc-2.13.03-1.mga6
nasm-debuginfo-2.13.03-1.mga6

Downloaded all the sample files and the Makefile from https://www.csee.umbc.edu/portal/help/nasm/sample_64.shtml and tried them out.

$ make all
That worked fine, compiling and running all the test files.
Corrected a couple of spelling mistakes and reran the tests.
$ make recompile
rm -f *.out
rm -f *.outc
make all
make[1]: Entering directory '/data/pad/qa/nasm'
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
< snipped >
7540113804746346429
-6246583658587674878
1293530146158671551
-4953053512429003327
-3659523366270331776
gcc -m64 fib.c
./a.out > fib.outc
rm -f a.out
nasm -f elf64 -l fib_64m.lst  fib_64m.asm
gcc -m64 -o fib_64m  fib_64m.o
./fib_64m > fib_64m.out
cat fib_64m.out
fibonacci numbers
              1
< snipped >
7540113804746346429
-6246583658587674878
1293530146158671551
-4953053512429003327
-3659523366270331776

No errors or problems of any kind reported.
This is good for x86_64.
Len Lawrence 2018-02-09 13:24:41 CET

Whiteboard: (none) => MGA6-64-OK

Comment 12 Len Lawrence 2018-02-12 00:47:12 CET
A minor test for 32-bit code on x86_64:

; hello_32.asm
bits 32
extern printf
global main

section .data
    message db "Hello world!!", 10, 0

section .text

main:
    pushad 
    push dword message
    call printf 
    add esp, 4 
    popad 
    ret
------------------------------------------------------------
Tried building 32-bit code on x86_64 and that worked fine.

$ nasm -f elf32 hello_32.asm
$ gcc -m32 hello_32.o -o hello32
$ ls
hello32*  hello_32.asm  hello_32.o
$ ./hello32
Hello world!!
Comment 13 Len Lawrence 2018-02-12 21:39:23 CET
Re fibonacci sequence in comment 11; I would guess that those negative numbers might have something to do with the sign bit being included in the integer case (unsigned long?).
Comment 14 Len Lawrence 2018-02-15 23:15:25 CET
Mageia 6 :: i586 in virtualbox

Downloaded samples from https://www.csee.umbc.edu/portal/help/nasm/sample.shtml
Repaired a few omissions and edited the makefile and ran it.  That worked fine.

Updated nasm and nasm-doc.
$ make clean
$ make all
nasm -f elf -l intarith.lst  intarith.asm
gcc -o intarith  intarith.o
./intarith
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 intarith.c
./a.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
rm -f a.out
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

That looks OK for 32 bits.

Whiteboard: MGA6-64-OK => MGA6-64-OK MGA6-32-OK

Comment 15 Len Lawrence 2018-02-15 23:30:19 CET
Apologies; noticed that the initial output was missing.  That was because of previous manual runs so make thought the targets were up-to-date.
$ make clean

Just showing the start of the listing:
$ make all
nasm -f elf -l hello.lst hello.asm
gcc -o hello  hello.o
./hello
Hello World
nasm -f elf -l printf1.lst  printf1.asm
gcc -o printf1  printf1.o
./printf1
a=5, eax=7
gcc printf1.c
./a.out
a=5, eax=7
rm -f a.out
nasm -f elf -l printf2.lst  printf2.asm
gcc -o printf2  printf2.o
./printf2
Hello world: a string of length 7 1234567 6789ABCD 5.327000e-30 -1.234568E+302
gcc printf2.c
./a.out
Hello world: a string 1234567 6789ABCD 5.327000e-30 -1.234000E+302 
rm -f a.out
nasm -f elf -l intarith.lst  intarith.asm
Comment 16 Len Lawrence 2018-02-15 23:35:24 CET
Created attachment 9991 [details]
Makefile and sample 32-bit programs
Comment 17 Len Lawrence 2018-02-16 19:49:35 CET
Needs the advisory to be pushed.  Validating anyway.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Thomas Backlund 2018-02-17 12:56:51 CET

CC: (none) => tmb
Keywords: (none) => advisory

Comment 18 Mageia Robot 2018-02-17 13:20:13 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0129.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.