Add a New Comment Rich Markup
version: master (commit 24f81be) poc: https://github.com/dandanxu96/PoC/raw/main/patch/patch-heap-use-after-free-poc command: patch -Rf < $poc$ Here is the trace reported by ASAN: ==2677==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020000005f0 at pc 0x555555586e60 bp 0x7fffffffdd10 sp 0x7fffffffdd00 READ of size 1 at 0x6020000005f0 thread T0 #0 0x555555586e5f in pch_write_line /home/user/test-data/patch/patch_lastest/patch/src/pch.c:2290 #1 0x555555575b7b in abort_hunk_context /home/user/test-data/patch/patch_lastest/patch/src/patch.c:1397 #2 0x555555575d06 in abort_hunk /home/user/test-data/patch/patch_lastest/patch/src/patch.c:1418 #3 0x555555571ef0 in main /home/user/test-data/patch/patch_lastest/patch/src/patch.c:489 #4 0x7ffff73c50b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) #5 0x55555556e3fd in _start (/home/user/test-data/patch/patch_lastest/patch/build/bin/patch+0x1a3fd) 0x6020000005f0 is located 0 bytes inside of 1-byte region [0x6020000005f0,0x6020000005f1) freed by thread T0 here: #0 0x7ffff769d7cf in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf) #1 0x555555580bc6 in another_hunk /home/user/test-data/patch/patch_lastest/patch/src/pch.c:1187 #2 0x5555555720d9 in main /home/user/test-data/patch/patch_lastest/patch/src/patch.c:408 #3 0x7ffff73c50b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) previously allocated by thread T0 here: #0 0x7ffff769dbc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8) #1 0x55555558ffea in savebuf /home/user/test-data/patch/patch_lastest/patch/src/util.c:869 #2 0x5555555825fa in another_hunk /home/user/test-data/patch/patch_lastest/patch/src/pch.c:1507 #3 0x5555555720d9 in main /home/user/test-data/patch/patch_lastest/patch/src/patch.c:408 #4 0x7ffff73c50b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) A heap use-after-free vulnerability is reported at src/pch.c:2290. After some analysis, I noticed that this vulnerability might share the same root cause as CVE-2019-20633 (still not fixed); thus, I attach my analysis for it. Hopefully, it will be of help. At the beginning of `another_hunk` function, the pointer in `p_line` is not set to NULL after it's freed. 1183 while (p_end >= 0) { 1184 if (p_end == p_efake) 1185 p_end = p_bfake; /* don't free twice */ 1186 else 1187 free(p_line[p_end]); 1188 p_end--; 1189 } In subsequent code, when `p_end=1`, we have `p_end = p_ptrn_lines + 1` (which is 5 in the poc) at line 1340. As a result, pointers with index=5 in p_line will be updated in line 1369, while p_line[1]~p_line[4] still keeps the danling pointers. 1335 if (p_end == 1) 1336 { 1337 /* 'Old' lines were omitted. Set up to fill 1338 them in from 'new' context lines. */ 1339 ptrn_missing = true; 1340 p_end = p_ptrn_lines + 1; 1341 ptrn_prefix_context = ptrn_suffix_context = -1; 1342 fillsrc = p_end + 1; 1343 filldst = 1; 1344 fillcnt = p_ptrn_lines; 1345 } ... 1369 if (! (p_line[p_end] = savestr (buf))) When `abort_hunk_context` is executed, it tries to access `p_line[0]`~`p_line[5]`, causing the UAF when dereferencing `p_line[1]` at pch.c:2290. 1340 static void 1341 abort_hunk_context (bool header, bool reverse) 1342 { 1343 lin i; 1344 lin pat_end = pch_end (); ... 1367 for (i=0; i<=pat_end; i++) { ... 1397 pch_write_line (i, rejfp); ... 1404 } 2286 bool 2287 pch_write_line (lin line, FILE *file) 2288 { 2289 bool after_newline = 2290 (p_len[line] > 0) && (p_line[line][p_len[line] - 1] == '\n');
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only logged-in users can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.12