4 ms·
Sure, you can corrupt all the data in your instance. You can't overwrite code or the true call stack, so what's the (security) risk?
by vardump 8y ago
Sure, you can corrupt all the data in your instance.
You can't overwrite code or the true call stack, so what's the (security) risk?
- pjmlp 8y agoFunny question, basically with corrupted data anything goes. For a very extreme convoluted example, maybe that value given back to the JavaScript layer will trigger a patient death by sending the wrong value to their insulin device monitor. But yeah, code and true call stack will be perfectly safe.
- vardump 8y agoOne day a random bit flip in a web app on a non ECC-protected iPad * controlling a life-critical system will kill a person. It's just a matter of time. * Or any other device with data corrupting hardware or software issues.
- pjmlp 8y agoYep it is just a matter of time. Successful lawsuits against insecure software need to become a common event until most companies actually start paying attention to their technology stack and development processes.
- ubercow13 8y agoIs that a security risk? That could just happen due to a logic bug.
- pjmlp 8y agoThat is the common excuse of C developers. The goal of software security is to minimize all attack vectors. Logic bugs < Logic bugs + Memory corruption bugs
- ubercow13 8y agoSure but Im not sure how your example is a security bug and not a normal bug? I guess if the web page was also processing untrusted data?