When assembling the attached ldlinux.asm from syslinux 3.31, nasm (built with -D_FORTIFY_SOURCE=2 as is standard for openSUSE) ist terminated by glibc because of stack smashing.
The command line for nasm is:
nasm -O99 -f bin -DDATE_STR="'0x480368b2'" -DHEXDATE="0x480368b2" -DMAP=ldlinux.map -l ldlinux.lst -o ldlinux.bin ldlinux.asm
The trace from glibc:
/lib/libc.so.6(__fortify_fail+0x4b)[0xf7ee962b]
/lib/libc.so.6(__fortify_fail+0x0)[0xf7ee95e0]
/usr/bin/nasm[0x8071181]
/usr/bin/nasm[0x8077b09]
/usr/bin/nasm[0x80721a1]
/usr/bin/nasm[0x80736d2]
/usr/bin/nasm[0x8075311]
/usr/bin/nasm[0x804adef]
/lib/libc.so.6(__libc_start_main+0xe6)[0xf7e1c5f6]
/usr/bin/nasm[0x8049061]
======= Memory map: ========
08048000-080a4000 r-xp 00000000 fd:05 6104257 /usr/bin/nasm
080a4000-080a5000 r--p 0005b000 fd:05 6104257 /usr/bin/nasm
080a5000-080a6000 rw-p 0005c000 fd:05 6104257 /usr/bin/nasm
080a6000-080b3000 rw-p 080a6000 00:00 0
09449000-09503000 rw-p 09449000 00:00 0 [heap]
f7db4000-f7dc0000 r-xp 00000000 fd:05 6101207 /lib/libgcc_s.so.1
f7dc0000-f7dc1000 r--p 0000b000 fd:05 6101207 /lib/libgcc_s.so.1
f7dc1000-f7dc2000 rw-p 0000c000 fd:05 6101207 /lib/libgcc_s.so.1
f7dc4000-f7e06000 rw-p f7dc4000 00:00 0
f7e06000-f7f43000 r-xp 00000000 fd:05 6100499 /lib/libc-2.8.so
f7f43000-f7f45000 r--p 0013d000 fd:05 6100499 /lib/libc-2.8.so
f7f45000-f7f46000 rw-p 0013f000 fd:05 6100499 /lib/libc-2.8.so
f7f46000-f7f4a000 rw-p f7f46000 00:00 0
f7f4b000-f7f4c000 rw-p f7f4b000 00:00 0
f7f4c000-f7f67000 r-xp 00000000 fd:05 6101024 /lib/ld-2.8.so
f7f67000-f7f68000 r--p 0001a000 fd:05 /lib/ld-2.8.so
f7f68000-f7f69000 rw-p 0001b000 fd:05 6101024 /lib/ld-2.8.so
ffd06000-ffd1b000 rw-p 7ffffffea000 00:00 0 [stack]
ffffe000-fffff000 r-xp ffffe000 00:00 0 [vdso]
The stack trace when __stack_chk_fail in glibc is called:
#2 0x08071181 in ppscan (private_data=0xffb0ce64, tokval=0xffb0ce4c) at preproc.c:1150
#3 0x08077b09 in evaluate (sc=0x8070e70 <ppscan>, scprivate=0xffb0ce64, tv=0x3fff, fwref=0x0, critical=1, report_error=0xfb, hints=0x0) at eval.c:852
#4 0x080721a1 in if_condition (tline=0xa03d160, ct=<value optimized out>) at preproc.c:1604
#5 0x080736d2 in do_directive (tline=0xa03d0f0) at preproc.c:2126
#6 0x08075311 in pp_getline () at preproc.c:3868
#7 0x0804adef in main (argc=12, argv=0xffb0d4b4) at nasm.c:1022
Logged In: YES
user_id=1874956
Originator: YES
I forgot to mention that this happens on i386 (current openSUSE FACTORY). On x86-64 ldlinux.asm is assembled without error.
Patch that fixes the stack overflow
Logged In: YES
user_id=1874956
Originator: YES
OK, a collegue here at SUSE identified the culprit:
preproc:1077
for (r = p, s = ourcopy; *r; r++) {
if (r == p+MAX_KEYWORD)
return tokval->t_type = TOKEN_ID; /* Not a keyword */
*s++ = tolower(*r);
}
ourcopy overflows because the ending '\0' hasn't been accounted for. Changing the test to
if (r >= p+MAX_KEYWORD)
like the attached patch does fixes the case. Just leaves the question why this didn't trigger on x86-64.
File Added: nasm-fix-crash.diff
Logged In: YES
user_id=58697
Originator: NO
Stack alignment is very different on x86-64, so that's not surprising.
Logged In: YES
user_id=58697
Originator: NO
This item has been resolved; the fix has been checked into git (http://repo.or.cz/w/nasm.git) and will be in the next release.
You can usually also obtain a nightly snapshot at ftp://ftp.zytor.com/pub/nasm/snapshots/; the snapshot robot usually runs some time between 09:00 and 10:30 UTC.
Logged In: NO
http://repo.or.cz/w/nasm.git?a=commit;h=76ec8e73db16f4cf1453a142d03bcc74d528f72f
Logged In: YES
user_id=1675598
Originator: NO
Does this also occur in 0.x series? I looked at 0.98.39 tarball to backport the supported patch, but couldn't identfy the vulnerable line.
if (tline->type == TOK_ID) {
tokval->t_charptr = tline->text;
if (tline->text[0] == '$') {
tokval->t_charptr++;
return tokval->t_type = TOKEN_ID;
}
if (!nasm_stricmp(tline->text, "seg"))
return tokval->t_type = TOKEN_SEG;
return tokval->t_type = TOKEN_ID;
}
Could someone shed light on this issue? I would really appreciate a patch for 0.x series if there is a security flaw in these series because not all distros use 2.x series.
Sourceforge.. May I repost it? :)
post a new one please