[Bug] Stack-buffer-overflow in ui_sc_msg via unsafe vsprintf usage

[oneafter]

Description

We discovered a Stack-buffer-overflow vulnerability in sc-im. The crash occurs in the ui_sc_msg function when parsing a crafted file containing an excessively long string.

The ASAN report indicates a WRITE memory violation where vsprintf writes past the bounds of a local stack buffer t.

Environment

• OS: Linux x86_64
• Complier: Clang
• Build Configuration: Release mode with ASan enabled.

Vulnerability Details

• Target: sc-im
• Vulnerability Type: CWE-121: Stack-based Buffer Overflow
• Function: ui_sc_msg
• Location: src/tui.c:262
• Root Cause Analysis: The function ui_sc_msg typically declares a fixed-size buffer (likely char t[1024], based on the ASAN report showing a 1024-byte region). It then uses vsprintf to format the message:

// src/tui.c
void ui_sc_msg(char * s, int type, ...) {
    char t[1024]; // inferred size
    va_list args;
    va_start(args, type);
    vsprintf(t, s, args); // Unsafe: no boundary check
    // ...
}

The PoC contains a very long line (@maxxxxxxxxx...). When the parser (yyparse) encounters this line, it likely attempts to display an error or status message containing this string. Since the formatted string exceeds 1024 bytes, vsprintf overflows the buffer t, corrupting the stack.

Reproduce

1. Build sc-im with Release optimization and ASAN enabled.
2. Run with the crashing file:

poc

" Th.
#A%"
l<.
forma
#B"
l ?h8
letmat ltt A2%
let A3 = @sum?2)
let = 28
@maxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0
?)
2 .
for A3 = @min(A1:c2,A2 > A1+A26)t \
A10
let A2 le
??? A2 Y 2
go:
2
let A3

./src/sc-im --nocurses --quit_afterload poc.sc

ASAN report

==3527==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f446ec04420 at pc 0x5595e35bcc94 bp 0x7fff89caee50 sp 0x7fff89cae5f0
WRITE of size 1038 at 0x7f446ec04420 thread T0
    #0 0x5595e35bcc93 in vsprintf (/src/sc-im/src/sc-im+0x75c93) (BuildId: a0e0444e0e3f03f87f10e6f4f651691f85705c2c)
    #1 0x5595e370b15e in ui_sc_msg /src/sc-im/src/tui.c:262:5
    #2 0x5595e36bff42 in yyparse /src/sc-im/src/gram.y:1263:22
    #3 0x5595e3686f3b in readfile /src/sc-im/src/file.c:901:36
    #4 0x5595e369eabf in load_tbl /src/sc-im/src/file.c:2287:37
    #5 0x5595e369e5b6 in load_file /src/sc-im/src/file.c:2248:5
    #6 0x5595e36f5e04 in main /src/sc-im/src/main.c:285:9
    #7 0x7f4472c7a1c9  (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e)
    #8 0x7f4472c7a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e)
    #9 0x5595e3595ba4 in _start (/src/sc-im/src/sc-im+0x4eba4) (BuildId: a0e0444e0e3f03f87f10e6f4f651691f85705c2c)

Address 0x7f446ec04420 is located in stack of thread T0 at offset 1056 in frame
    #0 0x5595e370aeef in ui_sc_msg /src/sc-im/src/tui.c:256

  This frame has 2 object(s):
    [32, 1056) 't' (line 259)
    [1184, 1208) 'args' (line 260) <== Memory access at offset 1056 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/src/sc-im/src/sc-im+0x75c93) (BuildId: a0e0444e0e3f03f87f10e6f4f651691f85705c2c) in vsprintf
Shadow bytes around the buggy address:
  0x7f446ec04180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f446ec04200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f446ec04280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f446ec04300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f446ec04380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7f446ec04400: 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
  0x7f446ec04480: f2 f2 f2 f2 00 00 00 f3 f3 f3 f3 f3 00 00 00 00
  0x7f446ec04500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f446ec04580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f446ec04600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f446ec04680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
==3527==ABORTING

[andmarti1424]

Hello. Could you please reattach the .sc file? The file you uploaded seems to have incorrect content. Thanks

[oneafter]

The file you uploaded seems to have incorrect content.

Yes, exactly. The content looks "incorrect" because it is a fuzzed file.

As you noted, the file is a malformed .sc document containing syntactically invalid commands and an excessively long string starting with '@'. This structure is purposely designed to trigger a syntax error in the parser.

Please try running sc-im (compiled with ASAN) against this file, and you should see the crash report. If you encounter any issues reproducing the crash, just let me know.

[andmarti1424]

I see. I imagine there are several ways to make sc-im crash editing the sc files or making them with invalid format / content.
I added these comments in sc generation routine to prevent users to do this kind of things:
This data file was generated by SCIM.
You almost certainly shouldn't edit it.

.sc files should be generated by the app itself not manually, unless you're sure how it works.

I dont say this is not a bug but there a lot of other bugs that has priority over this custom generated sc files errors.
And since this app is a one man only work and with little time available to work in this project (and certainly low support) I am afraid it wont be fixed in the near future.
Thanks for sharing though