New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stack based buffer overflow while parsing AQL (parsing next token) #594

Closed
cve-reporting opened this Issue Jul 9, 2018 · 0 comments

Comments

Projects
None yet
3 participants
@cve-reporting

cve-reporting commented Jul 9, 2018

Function next_token that provides next token during AQL parsing tries to memcpy input data (part of AQL files) into fixed size buffer.
Allocated buffer can fit only DB_MAX_ELEMENT_SIZE (16) bytes and the check is missing.
Crash line: aql-lexer.c:238

Declaration of buffer:

aql.h:117:
typedef char value_t[DB_MAX_ELEMENT_SIZE];

db_options.h:104:
#define DB_MAX_ELEMENT_SIZE 16

aql.h:123:
value_t value;

aql-lexer.c:119-125:
int
lexer_start(lexer_t *lexer, char *input, token_t *token, value_t *value)
{
lexer->input = input;
lexer->prev_pos = input;
lexer->token = token;
lexer->value = value;

Overflow:

aql-lexer.c:239:
memcpy(lexer->value, s, length);

This could lead to Remote Code Execution via stack smashing attack (overwriting the function return address).
The risk of this issue is reduced (Attack Vector:Local) because attacker would need to run malicious AQL query, however it is quite possible when using database in IoT application.

Proposed CVSS score:
CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (9.3 - critical)

Following AQL code will trigger crash (crash_001_next_token.sql):
E0000000000000000000000000000000000000000

Mitigation :
The size of input token should be limited to DB_MAX_ELEMENT_SIZE.
Please take a look at patch fixing this issue in TizenRT (using antelope engine as arastorage):
Samsung/TizenRT@bf7db98

Crash details using Address Sanitizer:

=================================================================
==10297==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc6d2ca440 at pc 0x7f1b281c0904 bp 0x7ffc6d2ca260 sp 0x7ffc6d2c9a08
WRITE of size 41 at 0x7ffc6d2ca440 thread T0
#0 0x7f1b281c0903 in __asan_memcpy (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x8c903)
#1 0x409c65 in next_token contiki-ng/os/storage/antelope/aql-lexer.c:239
#2 0x409c65 in lexer_next contiki-ng/os/storage/antelope/aql-lexer.c:267
#3 0x405192 in aql_parse contiki-ng/os/storage/antelope/aql-parser.c:795
#4 0x4019c1 in main contiki-ng/os/storage/antelope/test_aql.c:218
#5 0x7f1b27d8a82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#6 0x401c38 in _start (contiki-ng/os/storage/antelope/test_aql_asan.exe+0x401c38)

Address 0x7ffc6d2ca440 is located in stack of thread T0 at offset 240 in frame
#0 0x40500f in aql_parse contiki-ng/os/storage/antelope/aql-parser.c:779

This frame has 4 object(s):
[32, 36) 'token'
[96, 128) 'lex'
[160, 172) 'name'
[224, 240) 'value' <== Memory access at offset 240 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions are supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 __asan_memcpy
Shadow bytes around the buggy address:
0x10000da51430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000da51440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000da51450: 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3
0x10000da51460: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f4
0x10000da51470: f4 f4 f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 04
=>0x10000da51480: f4 f4 f2 f2 f2 f2 00 00[f4]f4 f3 f3 f3 f3 00 00
0x10000da51490: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00
0x10000da514a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000da514b0: 00 00 00 00 00 00 00 00 00 00 00 f4 f4 f4 f3 f3
0x10000da514c0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000da514d0: 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
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
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
==10297==ABORTING

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment