bugPSPP - Bugs: bug #54663, heap buffer overflow in is_end_data

 
 

bug #54663: heap buffer overflow in is_end_data

Submitted by:  Tianxiao Gu <tianxiaogu>
Submitted on:  Sat 15 Sep 2018 06:38:25 AM UTC  
 
Category:  Syntax Parser Severity:  5 - Average
Status:  Cannot Reproduce Assigned to:  None
Open/Closed:  Closed Release:  None
Effort:  0.00

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sat 29 Jun 2019 05:10:31 AM UTC, comment #2: 

This issue is not reproducible.   So either it has been fixed or we need further information.

Closing this issue until more information is forthcoming.

John Darrington <jmd>
Project Administrator
Mon 24 Sep 2018 06:18:19 AM UTC, comment #1: 

I was not able to reproduce this one.

Ben Pfaff <blp>
Project Administrator
Sat 15 Sep 2018 06:38:25 AM UTC, original submission:  

Function is_end_data in src/language/lexer/segment.c has a heap buffer overflow bug. To reproduce this bug, use the attached test-case-6 and run `pspp test-case-6`

=================================================================
==11557==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60c0000009c0 at pc 0x7f076b0ea874 bp 0x7ffdaee8b820 sp 0x7ffdaee8b818
READ of size 1 at 0x60c0000009c0 thread T0
    #0 0x7f076b0ea873 in c_strncasecmp /home/t/Projects/fuzzing/pspp/pspp/gl/c-strncasecmp.c:38:23
    #1 0x7f076b5d1b7b in is_end_data /home/t/Projects/fuzzing/pspp/pspp/src/language/lexer/segment.c:1354:22
    #2 0x7f076b5c9dd8 in segmenter_parse_begin_data_3__ /home/t/Projects/fuzzing/pspp/pspp/src/language/lexer/segment.c:1386:12
    #3 0x7f076b5c58f9 in segmenter_push /home/t/Projects/fuzzing/pspp/pspp/src/language/lexer/segment.c:1587:14
    #4 0x7f076b5b282d in lex_source_get__ /home/t/Projects/fuzzing/pspp/pspp/src/language/lexer/lexer.c:1393:21
    #5 0x7f076b5b1d1b in lex_get /home/t/Projects/fuzzing/pspp/pspp/src/language/lexer/lexer.c:228:10
    #6 0x7f076b5b8adf in lex_discard_rest_of_command /home/t/Projects/fuzzing/pspp/pspp/src/language/lexer/lexer.c:1113:5
    #7 0x7f076b5acbea in do_parse_command /home/t/Projects/fuzzing/pspp/pspp/src/language/command.c:244:3
    #8 0x7f076b5ac55f in cmd_parse_in_state /home/t/Projects/fuzzing/pspp/pspp/src/language/command.c:148:12
    #9 0x7f076b5acd7d in cmd_parse /home/t/Projects/fuzzing/pspp/pspp/src/language/command.c:163:10
    #10 0x5283ab in main /home/t/Projects/fuzzing/pspp/pspp/src/ui/terminal/main.c:138:20
    #11 0x7f07689acb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #12 0x41c459 in _start (/home/t/Projects/fuzzing/pspp/pspp/src/ui/terminal/.libs/pspp+0x41c459)

0x60c0000009c0 is located 0 bytes to the right of 128-byte region [0x60c000000940,0x60c0000009c0)
allocated by thread T0 here:
    #0 0x4e6c16 in realloc /home/t/Projects/lldb-testing/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:165
    #1 0x7f076b1488a8 in xrealloc /home/t/Projects/fuzzing/pspp/pspp/gl/xmalloc.c:61:7
    #2 0x7f076b148a1c in x2nrealloc /home/t/Projects/fuzzing/pspp/pspp/gl/./xalloc.h:207:10
    #3 0x7f076b148a73 in x2realloc /home/t/Projects/fuzzing/pspp/pspp/gl/xmalloc.c:76:10
    #4 0x7f076b5bc6ef in lex_source_expand__ /home/t/Projects/fuzzing/pspp/pspp/src/language/lexer/lexer.c:1170:25
    #5 0x7f076b5bb162 in lex_source_read__ /home/t/Projects/fuzzing/pspp/pspp/src/language/lexer/lexer.c:1184:7
    #6 0x7f076b5b284c in lex_source_get__ /home/t/Projects/fuzzing/pspp/pspp/src/language/lexer/lexer.c:1398:11
    #7 0x7f076b5b1d1b in lex_get /home/t/Projects/fuzzing/pspp/pspp/src/language/lexer/lexer.c:228:10
    #8 0x528385 in main /home/t/Projects/fuzzing/pspp/pspp/src/ui/terminal/main.c:135:3
    #9 0x7f07689acb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/t/Projects/fuzzing/pspp/pspp/gl/c-strncasecmp.c:38:23 in c_strncasecmp
Shadow bytes around the buggy address:
  0x0c187fff80e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c187fff80f0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c187fff8100: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa
  0x0c187fff8110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c187fff8120: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
=>0x0c187fff8130: 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa fa fa
  0x0c187fff8140: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c187fff8150: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c187fff8160: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
  0x0c187fff8170: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c187fff8180: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
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
==11557==ABORTING

Note that we found that AddressSanitizer may be in conflict with this project. Here is the analysis.

static bool
is_end_data (const char *input, size_t n)
{
  const uint8_t u_input = CHAR_CAST (const uint8_t , input);
  bool endcmd;
  ucs4_t uc;
  int mblen;
  int ofs;

  if (n < 3 || c_strncasecmp (input, "END", 3))
    return false;

  ofs = 3;
  mblen = u8_mbtouc (&uc, u_input + ofs, n - ofs);
  if (!lex_uc_is_space (uc))
    return false;
  ofs += mblen;

  // BUG: ofs will be first cast to unsigned. n - ofs will not be a negative number and then there is a buffer ovefflow in c_strncasecmp (input + ofs, "DATA", 4). Using our test case, n will be 3 and ofs will be 4.
  if (n - ofs < 4 || c_strncasecmp (input + ofs, "DATA", 4))
    return false;
  ofs += 4;

  ...
}

Tianxiao Gu <tianxiaogu>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #45014:  test-case-6 added by tianxiaogu (190B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jmd (Posted a comment)
  • -email is unavailable- added by blp (Posted a comment)
  • -email is unavailable- added by tianxiaogu (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-06-29 jmd Open/ClosedOpen => Closed
    2018-09-24 blp StatusNone => Cannot Reproduce
    2018-09-15 tianxiaogu Attached File- => Added test-case-6, #45014

    Back to the top


    Powered by Savane 3.5