Fix: Make it impossible to load dynamically generated shared libraries #5910
Conversation
hoodmane
force-pushed
the
hoodmane/prevent-loading-dynamic-shared-libs
branch
from
1996d75 to
7ef9c79
Compare
CodSpeed Performance ReportMerging this PR will degrade performance by 11.42%Comparing Summary
Performance Changes
Footnotes
|
| var libData = Module.patched_loadLibData(Module, f); | ||
| return flags.loadAsync ? Promise.resolve(libData) : libData; | ||
| } | ||
| function loadLibData1(){ |
There was a problem hiding this comment.
Well I'm trying to replace the definition of loadLibData. I'm replacing "function loadLibData(){" so after that there's a function body. I added my own function body but I need to define a new pointless function in order to discard the old function body.
There was a problem hiding this comment.
I see. How about using a more meaningful name such as loadLibDataPrivate for just in case?
| "function loadLibData(){", | ||
| """ | ||
| function loadLibData(){ | ||
| var f = findLibraryFS(libName, flags.rpath); |
There was a problem hiding this comment.
findLibraryFS probably doesn't exist in old Emscripten versions? I guess I added that in 4.X
There was a problem hiding this comment.
Indeed. My thought was to get it to work for 0.28.2 first and then work on 0.26 once that's working.
| # fmt: off | ||
| Path(tmp_path / "a.so").write_bytes( | ||
| bytes( | ||
| [ |
There was a problem hiding this comment.
Could you please add a comment about the content of this file?
| // Get the trusted read function from our private Map, not from the node | ||
| // or filesystem object (which could have been tampered with by user code) |
There was a problem hiding this comment.
Is this really something we should worry about? As long as users can access the Emscripten module object (I guess they can?), they can do anything.
I wonder if this additional barrier is really helpful.
There was a problem hiding this comment.
Users can access the Module object. However, they cannot access objects that are captured by closures. So patched_loadLibData can call UnsafeEval.newWasmModule(), but it is only willing to call it on read only data. The user could do all sorts of mischief with the file system, or even replace Module.patched_loadLibData with something else. But they can't import UnsafeEval into their own code, so they can only call it via the functions that call it that are attached to Module. As long as none of these functions are willing to compile arbitrary modules, we're okay.
2 participants
No description provided.