Open YoshiRulz opened 3 years ago
Seems reasonable, but what exactly are we trying to prevent here? How could an unexpected dynamic assembly reference come into existence?
The thing with unknown exploits is that they're unknown. That said, I think this is most relevent to ext. tools; I only noticed this potential vector when a dev in the ApiHawk Discord said that they threw their deps into /dll
(instead of the intended method) and EmuHawk loaded them without complaint.
edit:
The addon system is arbitrary native code. It can do anything it wants
Currently, yes. For the future, we could allow and block individual .NET APIs by inspecting assemblies before loading them. Space Engineers does just that. (Though it could be using compile-time checks to do it since you give it C# source. Still, it must be possible by introspection since this tool exists.)
Ehhhh. The addon system is arbitrary native code. It can do anything it wants; I wouldn't worry about this.
EmuHawk's deps are (or should be) known at compile-time, so we can codegen that list in. Then the event handler can reject any assembly which isn't in either that list or any ext. tool's
ExternalToolAttribute.LoadAssemblyFiles
list.