看板 C_and_CPP 關於我們 聯絡資訊
最近被問說 為什麼use after free後 你使用那塊memory的話 "有可能"會crash 或是 不會 我答不出來(這邊不討論 delete後 值被改動 foo->ptr已經變成垃圾指標 造成的acces s violation) 原因是 如果只是單純access 不管是read write, 我都不覺得會crash.... 以下是我 的測試和認知 https://ideone.com/HKYiIQ int* ptr = new int; *ptr = 123; cout << "before: " << ptr << ":" << *ptr << endl; (1) delete ptr; cout << "read after free: " << ptr << ":" << *ptr << endl; (2) *ptr = 456; // write after free cout << "read after free: "<< ptr << ":" << *ptr << endl; (3) 我的認知 new會透過cstdlib malloc要一塊 valid的user space address (他應該會跟OS要超過我d emand的) 然而我delete了 除了cstdlib裡面free做了一些事情外 , 他很可能也會跟OS講說我這塊 memory已經沒有要使用了(這邊不確定是不是每次 這是不是造成下面行為差異的主因) 再來我連續的 對這塊記憶體做讀取 和 寫入 1. 如果只是讀取而已 有沒有可能 造成crash? (以我測試來說 從沒因為read 而cras h, 但如果真的有可能會 我想知道為什麼) 2. 寫入比較不理解, 我拿到的是user space address, 雖然我delete了 但我write的時 候並沒有寫在其他超出user space的記憶體或是read-only的區段 為什麼 "有機會" 造成 SIGSEGV? 到底是誰 raise這signal? 3. 上面程式碼 (2) "有時候"會印出*ptr = 0,有時候是原來數值, 雖然我也只知道值不 可預期, 但我想問的是, 到底是誰把0 寫入進去? 是cstdlib嗎? 如果是的話 照理講要每 次都變0, 但顯然不是每次 以我測試, 如果我掛上valgrind ./a.out ==> 這行就不會變0 維持原來數值, 一旦直 接./a.out 就會是0 以上到底是誰介入了? 這件事我想說很可能是-O之類的差異 但我發現似乎不是 deb ug / release build都有這種現象. 然而有時候這一行就直接SIGSEGV了如同2.所問的問題 4. 我有用signal handler 擷取這SIGSEVG 我天真的想要把這件事給吃下來 但我看文章說 signal handler return後會回到 原本執行到的code 以我測試來說 我會 無限迴圈的觸發SIGSEGV , 想問一下是不是不可能吃得下來 一 定要 abort或是把handler設定成default 讓系統自己handle 5. 補個問題我嘗試在ubuntu產生core dump 大概做了幾件事 echo 'core_%e.%p' | sudo tee /proc/sys/kernel/core_pattern core_%e.%p ulimit -c unlimited gdb a.out --core=core_a.out.1234 想問說~ 難道一定要user自己在電腦想辦法開core dump的能力而無法透過自己applica tion 本身"暫時" 開啟嗎? 找不太到文章 以上雖然可以用undefined behavior來解釋 可是如果想知道更深入的概念 該怎麼做 謝謝 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.247.71.99 ※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1530680216.A.20F.html
Sidney0503: 違建拆除率低於50% 地震不是每個違建都會倒07/04 12:59
※ 編輯: lovejomi (27.247.71.99), 07/04/2018 13:18:56
yvb: (1) int* ptr = new int[65536]; 之類, new 較大空間看看. 07/04 13:47
L4ys: malloc 是一次跟 kernel 要一大塊來慢慢切給你用, free 掉 07/04 14:16
L4ys: 之後不會馬上還給 kernel, 寫了會 segfault 是因為 07/04 14:17
L4ys: freed chunk 上會存放一些資訊 07/04 14:18
L4ys: 另外如果 allocate size 超過 MMAP_THRESHOLD 則會改用 mmap 07/04 14:19
L4ys: /munmap, 這種 case 的 uaf 去讀取可能就會 segfault 07/04 14:21
L4ys: 想知道更深入的可以去看 malloc.c 07/04 14:21
F04E: ........ 07/04 18:29
lovejomi: 為什麼說使用mmap拿到的就肯定會sigsegv呢 07/04 19:01
yvb: 你可以用 strace 去觀察看看.mmap來的,free/delete時就還了. 07/04 19:32
b0920075: 哇是l4ys大大 07/05 09:48
b0920075: 還給kernel就相當於這塊memory不存在,你去訪問這地址當 07/05 09:48
b0920075: 然會crash 07/05 09:48