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

Missing bounds checks on DMA operations #1083

Open
mpharoah opened this issue Jun 10, 2024 · 3 comments
Open

Missing bounds checks on DMA operations #1083

mpharoah opened this issue Jun 10, 2024 · 3 comments

Comments

@mpharoah
Copy link
Contributor

mpharoah commented Jun 10, 2024

In this commit, there was a fix for an overflow in RSP DMAs, but none of the other missing bounds checks were fixed.

Here is a pull request that fixes all the DMAs in ParallelN64.

The mupen core has since moved around and refactored most of these places, so some of them may already be fixed; however, I can find some locations where vulnerabilities still exist:

There may be some other locations as well

@Reonu
Copy link

Reonu commented Jul 18, 2024

This makes the emulator vulnerable to ACE, is it seriously gonna get ignored?

@m4xw
Copy link
Contributor

m4xw commented Jul 18, 2024

This makes the emulator vulnerable to ACE, is it seriously gonna get ignored?

Its non-trivial and on a normal system with ASLR, its more a DOS than anything else, so severity is low. You could maybe ROP chain this if it leaks some infos but thats unlikely too, also any exploit will be bound to very specific builds of mupen as relative addr layouts would differ.
You should not run untrusted rom's, its that simple. Theres more ways to get code exec than this.

@mpharoah
Copy link
Contributor Author

mpharoah commented Jul 18, 2024

There's already an exploit out there in the wild for the RSP DMA overflow in unpatched paralleln64 on Windows that works consistently. And another one for Bizhawk on Windows. Considering these vulnerabilities are essentially the exact same vulnerability targeting the same region of memory (static data), I wouldn't dismiss the viability or severity of this. I doubt it would take many changes to the existing exploits to adapt either one to the other vulnerable DMA methods.

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

3 participants