#581 Global buffer overflow in the cb_push_op() function

[Frederic Cambus]

Hi,

While fuzzing gnucobol with Honggfuzz, I found a global buffer overflow in the cb_push_op() function, in field.c.

Attaching a reproducer, issue can be reproduced by running:

cobc test01.cob

=================================================================
==32328==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0000011b41f0 at pc 0x00000063c9f4 bp 0x7ffe9ee301d0 sp 0x7ffe9ee301c8
WRITE of size 1 at 0x0000011b41f0 thread T0
    #0 0x63c9f3 in cb_push_op /home/fcambus/gnucobol/cobc/field.c:216:19
    #1 0x62e85a in cb_evaluate_expr /home/fcambus/gnucobol/cobc/field.c:283:6
    #2 0x62d951 in cb_validate_78_item /home/fcambus/gnucobol/cobc/field.c:2538:15
    #3 0x561f53 in yyparse /home/fcambus/gnucobol/cobc/parser.y:6358:18
    #4 0x51d901 in process_translate /home/fcambus/gnucobol/cobc/cobc.c:6937:8
    #5 0x5014d7 in process_file /home/fcambus/gnucobol/cobc/cobc.c:8037:19
    #6 0x4faaaf in main /home/fcambus/gnucobol/cobc/cobc.c:8219:12
    #7 0x7f1d7df39b6a in __libc_start_main /build/glibc-KRRWSm/glibc-2.29/csu/../csu/libc-start.c:308:16
    #8 0x41c539 in _start (/usr/local/bin/cobc+0x41c539)

0x0000011b41f0 is located 48 bytes to the left of global variable 'op_prec' defined in 'field.c:59:15' (0x11b4220) of size 16
0x0000011b41f0 is located 0 bytes to the right of global variable 'op_type' defined in 'field.c:58:15' (0x11b41e0) of size 16
SUMMARY: AddressSanitizer: global-buffer-overflow /home/fcambus/gnucobol/cobc/field.c:216:19 in cb_push_op
Shadow bytes around the buggy address:
  0x00008022e7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008022e7f0: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
  0x00008022e800: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 00
  0x00008022e810: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
  0x00008022e820: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
=>0x00008022e830: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 00[f9]f9
  0x00008022e840: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x00008022e850: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
  0x00008022e860: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x00008022e870: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
  0x00008022e880: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==32328==ABORTING

[Simon Sobisch]

Assigned to Ron in the hope he find the time to recheck this.

[Frederic Cambus]

This issue got assigned CVE-2019-14468.

[Ron Norman]

The attached test program has a lot of garbage lines in it.
Is that the problem or was it not uploaded correctly?

[Ron Norman]

The test code had 300 dashes in one line.... -----------------
I think the compiler may be trying to table that up for evaluation as a constant expressions.
I will add some bounds checking on the tables and error off sooner on a table overflow.

[Simon Sobisch]

The attached test program has a lot of garbage lines in it.
Is that the problem or was it not uploaded correctly?

I've overlooked this at first sight, too - it is fuzzying so actually all about a broken source that was produced to brake cobc. Fixing any memory issues that come up with this can prevent security issues and in any case a nice error message like with the new expression overflow is much better than a possible "any possible strange behaviour" that is hard to debug.

With all latest changes in trunk this issue is not raised any more, instead GnuCOBOL raises the new expression overflow errors that Ron added for bug 582, so I'm closing this.

So @fcampus: thank you for fuzzying GnuCOBOL. You are invited to go on, but do note that the testsuite also fails with sanitizers active in tests 468 555 637 701 733 734 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 908 960 983 984 985 986 987 997 - so you may want to run the testsuite and file those issues before :-)
@fcampus: please "close" the CVEs and report its fixes to Debian as you've correctly created those in the first place.