3 ms·
That's exactly what the attacker wants you to do after their exploit runs: ignore the warning signs.
by buttercraft 2y ago
That's exactly what the attacker wants you to do after their exploit runs: ignore the warning signs.
- ndriscoll 2y agoYou don't ignore it. You track errors. What you don't do is crash the server for all users, giving an attacker an easy way to DoS you.
- buttercraft 2y agoA DoS might be the better option vs. say, data exfiltration.
- ndriscoll 2y agoMost bugs aren't going to create any risk for data exfiltration. In most real application servers (which are very rarely written in C or C++ these days), requests are almost completely isolated from each other except to the extent that they interact with a database. If you detect a bug in one request, you just abort the one request, and there's likely no way it could affect others. This is part of why something like Rust is usable at all; in the real world a lot of logic has straightforward, linear lifecycles. To the extent that it doesn't, you can push the long-lived state into something like an external database, and now your application has straightforward lifecycles again where the goal of a task is to produce commands to manipulate the database and then exit.
- buttercraft 2y agoSure, but i was talking about an individual process. If you don't know what state it's in, you simply can't trust it to run anymore. That's all.
- ndriscoll 2y agoExcept you usually can because the state isn't completely unknown. You might not expect some field in a structure to be null, but you still know for example that there's no way for one request to have a reference to another, so you just abort the one request and continue.
- buttercraft 2y agoNo, if you have been compromised, you cannot make these assumptions.
- joesb 2y agoAnd what does DOS attacker want you to do? Not crashing the whole service to deny others of the service?
- buttercraft 2y agoThat is a valid tradeoff in many situations, yes.