Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question on safe unlinking integrity check for mooosl #3

Open
jamestiotio opened this issue Sep 10, 2023 · 2 comments
Open

Question on safe unlinking integrity check for mooosl #3

jamestiotio opened this issue Sep 10, 2023 · 2 comments

Comments

@jamestiotio
Copy link

jamestiotio commented Sep 10, 2023

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

@jamestiotio jamestiotio changed the title Question on mooosl Question on safe unlinking integrity check for mooosl Sep 10, 2023
@ndrewh
Copy link
Contributor

ndrewh commented Sep 11, 2023

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
Copy link
Author

jamestiotio commented Sep 11, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants