#349 nasm 2.02 triggers stack guard in glibc 2.7

closed-fixed
5
2008-05-21
2008-04-14
No

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

Discussion

  • Philipp Thomas

    Philipp Thomas - 2008-04-14
     
  • Philipp Thomas

    Philipp Thomas - 2008-04-14

    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.

     
  • Philipp Thomas

    Philipp Thomas - 2008-04-15

    Patch that fixes the stack overflow

     
  • Philipp Thomas

    Philipp Thomas - 2008-04-15

    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

     
  • Philipp Thomas

    Philipp Thomas - 2008-04-15
    • assigned_to: nobody --> hpa
     
  • H. Peter Anvin

    H. Peter Anvin - 2008-04-15

    Logged In: YES
    user_id=58697
    Originator: NO

    Stack alignment is very different on x86-64, so that's not surprising.

     
  • H. Peter Anvin

    H. Peter Anvin - 2008-05-21
    • status: open --> closed-fixed
     
  • H. Peter Anvin

    H. Peter Anvin - 2008-05-21

    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.

     
  • Eren Türkay

    Eren Türkay - 2008-06-11

    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.

     
  • Nobody/Anonymous

    Sourceforge.. May I repost it? :)

     
  • Nobody/Anonymous

    post a new one please

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks