Emulator Issues #2742
closed
Added by BhaaL over 14 years ago.
Relates to performance:
No
Relates to maintainability:
No
Description
I don't want to commit this as half-assed way to validate ELF and DOL
files, requesting some review :)
http://pastie.org/984406
Can anyone think of other cases that should be validated before trying to
load one of those files? nakee did mention that we probably should validate
every memory access the code does; but apart from it slowing things down,
pretty much every file we load could contain malicious code.
This Validation is mainly meant to filter out things that might cause
unexpected behavior when loading files, as described in Issue 2739 - its
only possible to cause that behavior by modifying the ELF thats loaded to
access memory where it shouldnt be (why did it even get there? An .iso
should have hit a different branch than the one I'm patching).
I'm not sure this kind of validation is all that meaningful. Isn't it better to make
sure that the loading take place using memory write/read functions that are already
designed to be safe and not do crazy stuff, and maybe sanity check sizes during
loading?
It should weed out invalid files that might crash us, not prevent malicious code from
being run (at least not in first place). Plus its not that much work :p
Safe Read/Write functions would probably require a more/less complete rewrite of
CDolLoader and ElfReader, as they only take a pointer and work on it, without any
kind of validation.
The main piece in the puzzle is probably the change in CoreParameters::AutoSetup tho,
since ELF/DOL were not even trying to stop the boot process if anything went wrong.
- Status changed from New to Won't fix
Putting this one aside for now, gonna follow the other path along sane read/write
functions.
Issue 5019 has been merged into this issue.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by