3 ms·
Top comment from that post: > In this case, there are 4 bugs. One causes N++ to write 1 to 3 bytes past the end of a buffer, the other bugs cause N++ to read s
by notRobot 3y ago
Top comment from that post:
> In this case, there are 4 bugs. One causes N++ to write 1 to 3 bytes past the end of a buffer, the other bugs cause N++ to read some bytes past the end of heap objects, even the researchers aren't sure how they could be exploited.
> While it's good they're fixed, it looks pretty much like what you get running code in a fuzzer with ASan enabled - finding obscure and very difficult to exploit memory correctness bugs. Unless a miracle happens and those 3 bytes can be made to belong to some very important structure, there's not much can be done with control of those 3 bytes.
https://news.ycombinator.com/item?id=37321074 https://news.ycombinator.com/item?id=37321074
- LegionMammal978 3y agoIn fact, it's not even a 3-byte heap buffer overflow: it's a 1-byte overflow resulting from a 3-byte write operation. The relevant string on the heap is read precisely once, to insert the text into the current document, and freed once the file has finished loading (in the destructor of the Utf8_16_Read object). Therefore, the only thing that can be corrupted is the first byte in the Size field of the _HEAP_ENTRY corresponding to the subsequent object in the heap. However, some cursory research indicates that the 2 bytes of the Size field are protected (alongside the 1-byte Flags) by an XOR checksum stored in SmallTagIndex. Therefore, the worst it could ever do (unless I am missing something important) is cause an error when that subsequent object is freed. (Also, that particular write overflow is preceded by a 1-byte read overflow, but since the same buffer is reused for each block in the file, and since the bug can only occur after the first block, the read overflow will always read a byte from earlier in the same file.)