This vulnerability was analyzed during Episode 126 on 08 March 2022
The vulnerability here is just a straight forward case of reading a size from the attacker, and using it in a memcpy into a fixed size destination buffer on the stack.
A little bit interesting in this case was the exploitation strategy used. While nothing ground breaking normally the only primitive we’ve covered being gained from the stack-based overflow is hijacking the stored return address between stack frames. This exploit used the stack-based overflow to get a couple other primitives first by corrupting the locals on the stack.
- First the they were able to brute force a
client_sockvalue. When the file descriptor used here was invalid the function just returned so it was simple to just try a value and keep incrementing until it worked. - With the
client_sockleaked, there was theprefix_ptrandprefix_sizevalues which provided an arbitrary read primitive asprefix_sizebytes would be read fromprefix_ptrand sent out over the socket and then freed. The free was an important constraint on where theprefix_ptrcould point to, but otherwise it was arbitrary. They pointed it at the Global Offset Table (which for some reason worked despite thefreecall) to leak libc function pointers. With that they could calculate the address ofsystem - The next step with
systemleaked was to get data they control in a consistent location. This turned out to be fairly easy just requiring an allocation large enough to getmmap‘d. Which could be caused just by sending a large enough HTTP request in the first place. - And finally they had all the pieces necessary to use a more traditional route with a ret2lib style attack.
While nothing ground breaking, especially for those new to the field I often see stack based overflow basically just meaning overwrite ret, and they really can be much more powerful than just a control flow hijack.