You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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
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 astruct meta
does not have the "safe unlinking" integrity check (i.e.,cur->next->prev == cur
andcur->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
andcur->prev->next
to point to the same address of the fakestruct 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
The text was updated successfully, but these errors were encountered: