Conversation

at least once: CVE-2019-9195 Grin node (Rust) remote code execution vulnerability reported by grin-forum.org/t/critical-vul fixed in 1.02
Quote Tweet
My idea of remote code execution security is "Use Rust"; I would not be surprised if I screwed up once or twice. Looking forward to Philip Daian applying these new high standards to Emin "Sell your Bitcoin" Sirir. Or more importantly, his ridiculous Zcash claims. twitter.com/phildaian/stat…
Show this thread
Image
Image
1
4
Security best practices also don't just include using a memory safe language but also enforcing that nothing other than the update system can write to data that can be executed. A server process shouldn't be run with the privilege to modify itself or anything directly executable.
1
1
There's a mistake in the design of the system beyond just a specific file write bug if the file write bug can trivially lead to code execution, similarly to how using a language where common mistakes become exploitable memory corruption bugs is not just about individual mistakes.
1
It often does, but it doesn't when things are set up properly. The good old legacy *nix approach is having the application as a dedicated user not owning any of the code it uses or any data that it doesn't actually need to be able to write to at runtime. Also, enforcing noexec.
1
So in a case like that, only root can update the packages with the base code / data, and the server runs as www, which can't write to /var/www/html with static data / code since it should be owned by www-data. This applies to everything though, whether it's an Android app, etc.
1
Android is moving towards removing execute / execute_no_trans from app_data_file and forcing apps to execute libraries/executables from the library directory (managed by the package manager) or directly mapping libraries from the apk. It's one of the things I implemented before.
1
Show replies