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

1

5

4

Replying to

and

Well, at least it's not a memory corruption issue. Also love how archive directory traversal, which has been known for decades, suddenly has a funky name.

2

1

Replying to

and

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

Replying to

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

Replying to

and

in my experience path traversal -> code execution most of the time in practice

1

Replying to

and

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

Replying to

It can be enforced through another layer like SELinux in a more precise way, but the fundamentals are just *nix security 101. For example, for good old Linux / Apache web servers, there's generally a www user (which can't write to base server code / data) and a www-data user too.

1

1

Replying to

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

Replying to

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.

6:43 PM · May 13, 2019Twitter Web Client

Replying to

Of course, apps can still screw it up since there's more than native code execution, and fully preventing native code injection (removing execmem/execmod, ashmem execute, app_data_file execute) doesn't fix that. They can dynamically load data as code and pass to an interpreter.

1

Replying to

If you're using Rust, you don't have an eval function, or even any way of dynamically loading libraries via the standard library, so falling into that trap is way harder than with Java. Can obviously still fall into the trap, and developers need to be taught security 101 stuff.