2 ms·
> They did. Why would you say otherwise? Because I read the bug report? Where Epic specifically say they didn't fix the execution, instead they changed the sto
by Someone1234 8y ago
> They did. Why would you say otherwise?
Because I read the bug report? Where Epic specifically say they didn't fix the execution, instead they changed the storage context from External to Internal. The main issue is that they verify after download instead of before execution.
You put an exclusive write lock on the file, verify the file, and then execute the file without releasing the lock. It is what every other major installer or updater does. Epic's version instead downloaded the file, verified it, then [Sleep], and installed whatever was at that location. It is insecure.
- Dylan16807 8y agoInternal app-specific storage is private. That's all it needs to do. I'm not sure holding a lock even works to prevent file renaming on most OSes...
- namibj 8y agoMaybe a lock on the directory.
- im3w1l 8y agoInteresting! can you execute a file directly from the file descriptor though?
- Dylan16807 8y agoNo idea, but it doesn't need to execute it, it needs to trigger an install of it.
- zaarn 8y agoReplace execve with fexecve and you can run file descriptors.