yabasic memory corruption in variable assignments

[Jeremy]

Binary package hint: yabasic

A user can corrupt memory, possibly executing code during yabasic's parsing of BASIC files. Using a large value when assigning variables will overflow a buffer and corrupt memory (looks like it could be a pointer on the stack).

Description: Ubuntu 9.04
Release: 9.04

Package: yabasic
Status: install ok installed
Priority: optional
Section: interpreters
Installed-Size: 844
Maintainer: Ubuntu MOTU Developers <email address hidden>
Architecture: i386
Version: 2.763-4
Depends: libc6 (>= 2.4), libice6 (>= 1:1.0.0), libncurses5 (>= 5.6+20071006-3), libsm6, libx11-6
Description: Yet Another BASIC interpreter
 yabasic implements the most common and simple elements of the BASIC
 language; it comes with for-loops and goto with while-loops and
 procedures. yabasic does monochrome line graphics, and printing
 comes with no extra effort. yabasic runs under Unix and Windows;
 it is small (less than 200 KB) and free.
Original-Maintainer: Debian QA Group <email address hidden>

$ gdb /usr/bin/yabasic
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(no debugging symbols found)
(gdb) r /tmp/191.bas
Starting program: /usr/bin/yabasic /tmp/191.bas
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0xb7e1407a in strcmp () from /lib/tls/i686/cmov/libc.so.6
(gdb) i r
eax 0x4141412f 1094795567
ecx 0x99dfe38 161349176
edx 0x41414141 1094795585
ebx 0x99dfe38 161349176
esp 0xbfa9b76c 0xbfa9b76c
ebp 0xbfa9b7a8 0xbfa9b7a8
esi 0x41414141 1094795585
edi 0x0 0
eip 0xb7e1407a 0xb7e1407a <strcmp+10>
eflags 0x210246 [ PF ZF IF RF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb)

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

[Kees Cook (kees)]

*** buffer overflow detected ***: yabasic terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x37)[0x7f73cff6a5f7]
/lib/libc.so.6[0x7f73cff695a0]
/lib/libc.so.6[0x7f73cff68457]
yabasic[0x403920]
yabasic[0x41c56f]
yabasic[0x407097]

0x000000000040391b <dotify+139>: callq 0x403058 <__strcat_chk@plt>

from yyparse. Looks like:

char *
dotify (char *name, int addfun) /* add library name, if not already present */
{
  static char buff[200];
  if (!strchr (name, '.'))
    {
      strcpy (buff, currlib->s);
      strcat (buff, ".");
      strcat (buff, name);
...

[Kees Cook (kees)]

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

system("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 yabasic?

[Graham Inggs (ginggs)]

Still present in yabasic 1:2.77.2-1

[Graham Inggs (ginggs)]

Forwarded:
https://github.com/marcIhm/yabasic/issues/5

[Launchpad Janitor (janitor)]

This bug was fixed in the package yabasic - 1:2.77.3-1

---------------
yabasic (1:2.77.3-1) unstable; urgency=medium

  * New upstream release
    - Fixed insecure usage of strcpy (LP: #424602)
    - Better logging for windows installer
    - Spelling corrections
  * Drop patches included upstream and refresh remaining
  * Update debian/copyright, drop comment about old licensing
  * Fix strncpy() issue when regenerating flex parser

 -- Graham Inggs <email address hidden> Wed, 04 Jan 2017 11:28:12 +0200