search

cscosu / ctf-writeups

Write-ups for the Buckeye Bureau of BOF
27 stars 5 forks source link

Question on safe unlinking integrity check for `mooosl` #3

Open jamestiotio opened 1 year ago

jamestiotio commented 1 year ago

Hi there! First of all, thank you for sharing these great CTF writeups! They are useful for others to learn more about these cybersecurity topics.

I would like to kindly check about something related to the mooosl challenge writeup.

In the Semi-arbitrary write section, it was mentioned that the dequeue function to unlink a struct meta does not have the "safe unlinking" integrity check (i.e., cur->next->prev == cur and cur->prev->next == cur).

If the integrity check was present, could you kindly elaborate on how it would prevent the exploit from being successfully executed? Couldn't we simply control the values of cur->next->prev and cur->prev->next to point to the same address of the fake struct meta so that it passes such an integrity check? Or is this action being prevented by something that I am not aware of?

Do let me know your thoughts on this. @ndrewh

Thank you!

Best regards, James Raphael Tiovalen

ndrewh commented 1 year ago

It's been a long time since that write-up, but I can try to answer.

This is the access that we are using to get arbitrary write ("where to write" = cur->next and "what to write" = cur->prev)

cur->next->prev = cur->prev;

Couldn't we simply control the values of cur->next->prev and cur->prev->next

I don't think we can. If we already controlled the value of cur->next->prev then we wouldn't be trying to overwrite it in the first place.

Hope this helps!

jamestiotio commented 1 year ago

If we already controlled the value of cur->next->prev then we wouldn't be trying to overwrite it in the first place.

Ah good point.

I would assume that if the integrity check (cur->next->prev == cur and cur->prev->next == cur) is present, then we would not have an arbitrary write as the values that cur->next and cur->prev can take would be restricted, which would make it much harder to exploit, right? Am I correct in this regard?

And would there be any other impact on the exploitability of mallocng if the check is implemented? @ndrewh

Thank you!

Best regards, James Raphael Tiovalen