tag:blogger.com,1999:blog-7684737362922576550.post824197754053313324..comments2023-04-13T11:29:20.429+02:00Comments on Dragon Sector: 0CTF 2017 - UploadCenter (PWN 523)Gynvael Coldwindhttp://www.blogger.com/profile/03896699037255726570noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-7684737362922576550.post-34753054963686535512017-03-21T10:31:22.864+01:002017-03-21T10:31:22.864+01:00One thing to add:
- the main thread did read(1) o...One thing to add:<br /><br />- the main thread did read(1) on stdin<br />- the controlled thread did read(controlled size, probably limited to TCP window size cross kernel buffering done during thread being asleep) on stdin<br /><br />So after the controlled thread won the race, the main thread stopped being a problem instantly (i.e. the rest of the stage 2 payload from that point on was read correctly).<br />Gynvael Coldwindhttps://www.blogger.com/profile/03896699037255726570noreply@blogger.comtag:blogger.com,1999:blog-7684737362922576550.post-90699104881292172142017-03-21T10:27:51.504+01:002017-03-21T10:27:51.504+01:00Thanks! :)
So what I didn't write above (and p...Thanks! :)<br />So what I didn't write above (and probably should have) is that the mmapped area was RW-, so execution was not possible on the PNG pages (and NX was enabled). Therefore I had to fallback to the usual methods (i.e. ROP).<br /><br />The racing could have been avoided if I would know libc address before preparing stage 1 ROP (so I could use execve function call or syscall gadgets). I could know it since there was a small stack leak in option 1, but I decided to ignore it and leak libc in stage one, and then do the race.<br /><br />The race was rather simple btw - according to my measurements the main thread won the race for stdin read about 4-10 times before the controlled thread would win it. Each time the main thread won the race it grabbed 1 byte from stdin, therefore 4-10 bytes were missing each time. Given that I used an additional alignment in my shellcode (so it could be 'eaten off' by the main thread) it boiled down to hitting the correct number of races won by main thread. My bet was on 8, 16 or any other product of 8, since that was that was the size of my ROP nop sled (i.e. if one item of the nopsled would be correctly 'eaten off', the rest of the shellcode would execute).<br />So the theoretical probability of this happening was bout 1/7, and in practice I hit in in 2-3 try (after I got my stage 2 working locally that is).<br /><br />In the end the race wasn't a big problem. It just had to be accounted for :)Gynvael Coldwindhttps://www.blogger.com/profile/03896699037255726570noreply@blogger.comtag:blogger.com,1999:blog-7684737362922576550.post-54283430531243826812017-03-20T22:15:21.375+01:002017-03-20T22:15:21.375+01:00Nice write-up !
Question: Couldn't you have un...Nice write-up !<br />Question: Couldn't you have unmapped the stack and remapped with new PNG containing the execve shellcode instead of racing with the main thread for stdin ?Anonymoushttps://www.blogger.com/profile/04535544616109116833noreply@blogger.com