Join GitHub today
Several security vulnerabilities in ELF file parser #255
Curious of the ELF file loading functionality in VBA-M that I accidentally discovered a few days ago, I quickly looked through the code responsible of making it work.
Particularly, one of the vulnerabilities is fully exploitable on the Windows platform and allows for information disclosure. The emulated ROM can access arbitrary information from the emulator's process memory, as seen from this screenshot: https://cdn.pbrd.co/images/HpKVzGP.png
The original plan was to privately disclose any details related to these bugs to the project owner, to have them fixed before publishing any information - however, seeing that this is an open-source project with large amount of contributors, and the project site doesn't give any means of private contact, I'm forced to just submit an issue publicly.
(1) In handling of both PT_LOAD segments and SHT_PROGBITS sections,
The offsets and addresses are loaded directly from the ELF image and they are not sanitized in any way, excluding the starting if statement. There are two potential problems here:
An example solution to this problem would be to validate whether all the pointers are in bounds before using them.
(2) The e_shstrndx field in the program header should determine the index in the section header table that represents the section name table's entry. A value of 0 indicates that the loaded image has no sections (and thus, no name table). This case is handled as follows:
A solution to this problem would be either to parse section headers if and only if e_shstrndx is nonzero, or make
(3) VBA (and consequently, VBA-M) support loading symbols encoded in
Interestingly, if a symbol table is loaded, there is some code logic that displays the symbol names in the built-in disassembly window (but only for the THUMB instruction set, for unknown reason). However, the buffer allocated for each disassembled instruction is only 80 bytes in size, as seen below.
Combine that with the 255-character symbol names to get a rather standard buffer overflow.
Note: All details of the found vulnerabilities, including proof of concept exploits, will be fully disclosed after 14 days (June 27th, 2018), unless the parties agree on extending that period to a maximum of 21 days (July 4th, 2018).
I much appreciate the detailed report. Even though I am project lead currently, time is a bit of an issue for me (full time job eating what free time I have lately) I'll see about getting this vulnerability fixed asap. I'll also see about providing a way to contact us if preffered privately first for future.
Thank you for your response. During the past week the repository seemed to be fairly active, which left me under the impression that this issue is being ignored. Sorry for the misunderstanding.
Now that I see the problem is being worked on, there's no need to rush anyone - so I'm willing to agree on a longer disclosure period.
I'll be sure to drop in on IRC when I'm free.
I examined the changes and didn't immediately find any problems. I believe these modifications are sufficient to prevent all the described issues from happening.
I would only be cautious about this check:
There are some later checks that seem to catch this and prevent any damage, but I think it's better to just avoid the whole scenario, by checking for