What we really mean when we talk about 'vulnerability'

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
A diagram showing what we are looking for when trying to find vulnerabilities in various codebases from both the perspective of LangSec[1] (unexpected states, circle on the left) and the dataflow model(tainted data flows, the ring on the right)

More or less, there are almost certainly some states and state transitions("the weird machine") that "did exist but unknown and unexpected to the programmer" - in every single codebase.

Simply put, what hackers do is to reveal those state transitions and somehow force the program/automaton into such an unexpected state through an unexpected(from the programmer's perspective) state transition, which is initiated by a user-crafted data flow. The only way to get it done safely is to let your expectation precisely match the weird machine actually being implemented by either expanding your expectation or diminishing the "weird part" in your automaton.

Furthermore, there are two subtly separate scenarios, one is when we have some assumptions about the data flow in order for the control flow to function properly(within our expectations), and the other is when the data flow has no influence on the control flow's behaviour, only the former is predisposed to be exploited.


It is from a technical viewpoint and has nothing to do with some so-called "branches of security", such as OpSec, and Unauthorized Access, which should be included in your expectation from the outset. Likewise for Reverse Engineering, Forensics, Backdoor, Malware, etc. (without any exploitation involved)

vulns:
having indirect(as well as unexpected) influence on the control flow using merely dataflow (technically, those weird computations have been defined in that control flow unintentionally by the developer, all the hackers do is to find a way(dataflow) to trigger that hidden computation)
malware/hooks/RE etc.
you are directly dealing with the control flow itself either by creating your own or revealing/modifying someone else's

The key here is whether or not there are any *unexpected state transitions* (a.k.a. the weird machine) and exploitable behaviour involved in the weird part of that target automaton, which is caused by unexpected dataflow.

"The system's security is defined by what computations can and cannot occur in it under all possible inputs[2]" after all, cyber security research is all about trying to figure out how things really work under all possible(and impossible :) circumstances, both expectedly and unexpectedly. (that is, exploring the unexpectedness)

Just my humble opinion, feel free to correct me.

References:

[1] http://langsec.org/papers/Bratus.pdf

[2] http://langsec.org/papers/langsec-tr.pdf

[3] http://langsec.org/papers/langsec-cwes-secdev2016.pdf

点击右边的按钮加载评论,如果无法加载那估计是被墙啦..你看着办w