Hacker News Reader

It is unrelated. For example the input may be used only as a parameter for reading operations - ie. one can easily imagine a situation where even in a safest language using un-validated input may result in a call/query producing info outside of what would be expected for valid parameters.

View on HN

You can create special purpose languages which lean on type safety heavily to just outright forbid this sort of error at compilation. "This is an untrusted input byte, those range from 0 to 255, so the rest of the code must work for all values in that range or else that's a build error".

Languages like that aren't going to be suitable for writing a whole web browser or a desktop operating system, but they might well be enough for the Titan chip. This is the sort of work where the compilation is tricky (definitely wouldn't fit on a small ARM core) but the machine code it spits out is much the same except safe.

Yes, one can always imagine such a scenario. However, more often than not, real discovered vulnerabilities (that is, vulnerabilities in the real world, not some hypothetical situation) seem to exploit permissive memory modification in C/C++. In the scenario you describe, even discovering the vulnerability would require deeply understanding the application logic. In the vulnerability discussed here, simply fuzzing was enough to discover the vulnerability because it was easy to detect the invalid memory access.

Reply on news.ycombinator.com