bwbasic buffer overflow in variable assignments

[Jeremy]

Binary package hint: bwbasic

There is a buffer overflow in bwbasic parsing BASIC files. Using a large value when assigning variables will overflow a buffer and overwrite the return address.

Description: Ubuntu 9.04
Release: 9.04

Package: bwbasic
Status: install ok installed
Priority: optional
Section: interpreters
Installed-Size: 392
Maintainer: Ubuntu MOTU Developers <email address hidden>
Architecture: i386
Version: 2.20pl2-9
Depends: libc6 (>= 2.6.1-1)
Description: Bywater BASIC Interpreter
 The Bywater BASIC Interpreter (bwBASIC) implements a large superset
 of the ANSI Standard for Minimal BASIC (X3.60-1978) and a significant
 subset of the ANSI Standard for Full BASIC (X3.113-1987) in C. It
 also offers shell programming facilities as an extension of BASIC.
 bwBASIC seeks to be as portable as possible.
Original-Maintainer: Vince Mulhollon <email address hidden>

**************************************************
*
* PATH: [/usr/bin/bwbasic]
* SIGNAL: 6 (SIGABRT)
* FILE: [/tmp/191.bas]
* DATA: Overflow: A x 550
*
* EAX = 0x0
* ECX = 0x7f01
* EDX = 0x6
* EBX = 0x7f01
* ESP = 0xbf928ed8
* EBP = 0xbf928ef0
* ESI = 0x0
* EDI = 0xb7ed0ff4
* EIP = 0xb7f10430
*
***************************************************

*** stack smashing detected ***: /usr/bin/bwbasic terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb8009da8]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb8009d60]
/usr/bin/bwbasic[0x804e7af]
[0x41414141]
======= Memory map: ========
08048000-08062000 r-xp 00000000 08:01 675369 /usr/bin/bwbasic
08062000-08065000 rw-p 0001a000 08:01 675369 /usr/bin/bwbasic
08065000-0806e000 rw-p 08065000 00:00 0
0907e000-09144000 rw-p 0907e000 00:00 0 [heap]
b7e64000-b7f0c000 rw-p b7e64000 00:00 0
b7f0c000-b8068000 r-xp 00000000 08:01 1172698 /lib/tls/i686/cmov/libc-2.9.so
b8068000-b8069000 ---p 0015c000 08:01 1172698 /lib/tls/i686/cmov/libc-2.9.so
b8069000-b806b000 r--p 0015c000 08:01 1172698 /lib/tls/i686/cmov/libc-2.9.so
b806b000-b806c000 rw-p 0015e000 08:01 1172698 /lib/tls/i686/cmov/libc-2.9.so
b806c000-b806f000 rw-p b806c000 00:00 0
b806f000-b8093000 r-xp 00000000 08:01 1172706 /lib/tls/i686/cmov/libm-2.9.so
b8093000-b8094000 r--p 00023000 08:01 1172706 /lib/tls/i686/cmov/libm-2.9.so
b8094000-b8095000 rw-p 00024000 08:01 1172706 /lib/tls/i686/cmov/libm-2.9.so
b8098000-b80a5000 r-xp 00000000 08:01 1155137 /lib/libgcc_s.so.1
b80a5000-b80a6000 r--p 0000c000 08:01 1155137 /lib/libgcc_s.so.1
b80a6000-b80a7000 rw-p 0000d000 08:01 1155137 /lib/libgcc_s.so.1
b80a7000-b80aa000 rw-p b80a7000 00:00 0
b80aa000-b80ab000 r-xp b80aa000 00:00 0 [vdso]
b80ab000-b80c7000 r-xp 00000000 08:01 1155095 /lib/ld-2.9.so
b80c7000-b80c8000 r--p 0001b000 08:01 1155095 /lib/ld-2.9.so
b80c8000-b80c9000 rw-p 0001c000 08:01 1155095 /lib/ld-2.9.so
bfcb3000-bfcc8000 rw-p bffeb000 00:00 0 [stack]

[191.bas]
fuzz = AAAAA..... x 512 (example value, probably not exact)
[/191.bas]

[Kees Cook (kees)]

I've reproduced this, here is the trace of the failure location...

#4 0x00007fc94e7675c0 in __stack_chk_fail () from /lib/libc.so.6
No symbol table info available.
#5 0x000000000040684e in exp_isufn (expression=<value optimized out>)
    at bwb_exp.c:994
        f = 0x628420
        tbuf = 'A' <repeats 41 times>
#6 0x0000000000406afb in exp_findop (expression=<value optimized out>)
    at bwb_exp.c:658
        c = <value optimized out>
        rval = 0
        cbuf = 'A' <repeats 63 times>, "\0\0\0\0\0\0\0\0\0t\31@", '\0' <repeats 29 times>, "G\32@", '\0' <repeats 13 times>, "\f @", '\0' <repeats 2077 times>, "G\232\306N\311\177", '\0' <repeats 75 times>, "`\26\0\0\0\0\0TR\26\0\0\0\0\0TR\26", '\0' <repeats 13 times>, "\5\0\0\0\0\0\0\0\0P6\0\0\0\0\0\0\240\66\0\0\0\0\0\230\235\66\0\0\0\0\0\b\350\66\0\0\0\0\0\0P\26\0\0\0\0\0\3", '\0' <repeats 16 times>, " \b\0\0\0\0\0X\37\b\0\0\0\0\0X\37\b", '\0' <repeats 13 times>, "\5\0\0\0\0\0\0\0\0 (\0\0\0\0\0\0@(\0\0\0\0\0\220"...
        nbuf = 'A' <repeats 63 times>, "\0\0\0\0\0\0\0\0\0\322\30@\0\0\0\0\0bwBASIC: ", '\0' <repeats 4839 times>, "\5\0\0\0\0\0\0\0p", '\0' <repeats 31 times>, "XPE\2\0\0\0\0H\0\0\0\0\0\0\0@\256\235N\311\177\0\0P\236\1\0\0\0\0\0\260"
        position = 63
        adv_loop = <value optimized out>

[Kees Cook (kees)]

On examination, it seems that exp_getvfname() has no length-checking, so
the exp_isufn() "tbuf" variable is overflowed if "expression" is longer
than MAXVARNAMESIZE (40).

[Kees Cook (kees)]

As it turns out, bwbasic passes shell commands, so this is does not create a new problem:

bwBASIC: uname -a
Linux gorgon 2.6.31-10-generic #30-Ubuntu SMP Tue Sep 8 12:32:38 UTC 2009 x86_64 GNU/Linux

[Jeremy (0xjbrown41)]

What does bwbasic passing shell commands have to do with a clear buffer overflow in parsing variable assignments? I understand that a user could craft a .bas file to execute shell commands, but using that in regard to this vulnerability is more of a conditions clause than a negation

[Kees Cook (kees)]

I may be dense, but a buffer overflow it's any worse than arbitrary shell command execution. Are there conditions where this buffer overflow is possible without creating a crafted .bas file?

[Jeremy (0xjbrown41)]

Executing code on the stack and executing shells commands is completely different, although one or the another or a combination of both can be used as forms of exploitation. Shell commands just happens to be something bwbasic parses in .bas files, something that is meant to happen, and executing code on the stack by overflowing a buffer and overwriting the return address clearly is not. I'm not saying the environment is going to be very clear and reasonable, but that a buffer overflow in parsing .bas files is a security issue that should be fixed.

[Kees Cook (kees)]

As an attacker, I can gain control of the process through shell commands or through stack overflows, so if shell command access is "by design", stack overflows are no worse (from a security perspective). This is absolutely a bug, since the process will crash due to the stack protector checks, but I don't see how it's a security issue.