Skip to content

Commit 2847342

Browse files
konradweissKuechAoxisto
authored
Adding pages extracted from the wiki pages (#1850)
* Addin parts extracted from the wiki pages * Add new pages to index * Removed the query exampel from navigation, moved principles to implementation --------- Co-authored-by: KuechA <31155350+KuechA@users.noreply.github.com> Co-authored-by: Christian Banse <christian.banse@aisec.fraunhofer.de>
1 parent 897955d commit 2847342

File tree

3 files changed

+185
-0
lines changed

3 files changed

+185
-0
lines changed
Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
# Design Principles
2+
3+
## The CPG represents the code's ...
4+
5+
* Structure/Syntax
6+
* Data Flows
7+
* Execution Order/Control Flow
8+
* Variable Usage
9+
* Calls
10+
* The Type System
11+
12+
## The CPG should parse ...
13+
14+
* Incomplete code
15+
* Code with missing toolchains
16+
* With resilience to incorrect code
17+
* Language heterogeneous projects
18+
19+
20+
## CPG-Library users should be able to ...
21+
22+
* Load projects and single files
23+
* Visualize and analyze code
24+
* Implement and register new Language Frontends
25+
* Extends and modify existing components, e.g., passes
26+
* Parse code incrementally
27+
28+
## The CPG-Transformation should be ...
29+
* Language independent: Allow for language independent and cross-language queries
30+
* Information-rich: contain language-specific information in generalized structures
31+
* Fast (enough).
32+
* Small Projects/Development projects should be analyzable in real-time, at most some seconds.
33+
* Large libraries should take no longer than a few hours.
34+
* About 5 to 10 times as long as the compilation process.
Lines changed: 150 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,150 @@
1+
# Query Examples
2+
3+
We want to create a way to create "rules" or "checks", that check for certain patterns in the code. Therefore we need to decide, if we want to have a "algorithmic" or a "descriptive" way to declare such as check.
4+
5+
Syntax explanation: `|x|` means, that `x` should be "resolved", either through constant propagation or other fancy algorithms.
6+
7+
The following examples check that no such bug is present.
8+
9+
## Array out of bounds exception
10+
11+
Part of: CWE 119
12+
```
13+
result.all<ArraySubscriptionExpression>(mustSatisfy = { max(it.subscriptExpression) < min(it.size) && min(it.subscriptExpression) >= 0 })
14+
```
15+
16+
## Null pointer dereference (CWE 476)
17+
18+
```
19+
result.all<HasBase>(mustSatisfy={it.base() != null})
20+
```
21+
22+
## Memcpy too large source (Buffer Overflow)
23+
Part of CWE 120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') --> do we also need to find selfwritten copy functions for buffers?
24+
```
25+
result.all<CallExpression>({ it.name == "memcpy" }, { sizeof(it.arguments[0]) >= min(it.arguments[2]) } )
26+
```
27+
28+
## Memcpy too small source
29+
30+
```
31+
result.all<CallExpression>({ it.name == "memcpy" }, { sizeof(it.arguments[1]) <= max(it.arguments[2]) } )
32+
```
33+
34+
## Division by 0 (CWE 369)
35+
36+
```
37+
result.all<BinaryOperator>({ it.operatorCode == "/" }, { !(it.rhs.evaluate(MultiValueEvaluator()) as NumberSet).maybe(0) } )
38+
```
39+
40+
## Integer Overflow/Underflow (CWE 190, 191, 128)
41+
42+
For assignments:
43+
```
44+
result.all<Assignment>({ it.target?.type?.isPrimitive == true }, { max(it.value) <= maxSizeOfType(it.target!!.type) && min(it.value) >= minSizeOfType(it.target!!.type)})
45+
```
46+
For other expressions, we need to compute the effect of the operator
47+
48+
## Use after free
49+
50+
Intuition: No node which is reachable from a node `free(x)` must use `x`. Use EOG for reachability but I'm not sure how to say "don't use x". This is the most basic form.
51+
```
52+
result.all<CallExpression>({ it.name == "free" }) { outer -> !executionPath(outer) { (it as? DeclaredReferenceExpression)?.refersTo == (outer.arguments[0] as? DeclaredReferenceExpression)?.refersTo }.value }
53+
```
54+
55+
## Double Free
56+
57+
```
58+
result.all<CallExpression>({ it.name == "free" }) { outer -> !executionPath(outer) { ((it as? CallExpression)?.name == "free" && ((it as? CallExpression)?.arguments?.getOrNull(0) as? DeclaredReferenceExpression)?.refersTo == (outer.arguments[0] as? DeclaredReferenceExpression)?.refersTo }.value }
59+
```
60+
61+
## Format string attack
62+
63+
arg0 of functions such as `printf` must not be user input. Since I'm not aware that we have a general model for "this is user input" (yet), we could say that all options for the argument must be a Literal (not sure if the proposed notation makes sense though).
64+
```
65+
vuln_fcs = ["fprint", "printf", "sprintf", "snprintf", "vfprintf", "vprintf", "vsprintf", "vsnprintf"];
66+
forall (n: CallExpression): n.invokes.name in vuln_fcs => forall u in |backwards_DFG(n.arguments[0])|: u is Literal
67+
```
68+
69+
Since many classical vulns. (injection) are related to user input, we probably need a way to specify sources of user input (or "sources" in general). To reduce FP, we probably also want to check some conditions over the path between the source and the sink (e.g. some checks are in place to check for critical characters/substrings, do escaping, etc.). Problem: There are tons of options.
70+
71+
## Access of Uninitialized Pointer (CWE 824)
72+
73+
## Access of Invalid Memory Address
74+
75+
## Unsecure Default Return Value
76+
77+
Sounds like this always depends on the program? What is an insecure return value?
78+
79+
E.g.:
80+
* Authorization: instead of assuming successful authorization (`authorized = true`) and checking for the contrary; start with assuming unauthorized (`authorized = false`) and check for authorization
81+
82+
## Missing Return Value Validation (Error checking)
83+
84+
CWE 252
85+
86+
I can't think of a simple query here which does not introduce too many findings because it often depends "what happens afterwards". Example: logging an error value is typically not problematic. Also, the return values can have very different meanings which makes it hard to find a solution for all issues.
87+
88+
Simple idea 1: There has to be at least a check for the return value (probably for a given list of functions and respective error indicating return values).
89+
90+
## Command Injection
91+
92+
* Perform data flow analysis and check if unchecked user input reaches function calling system commands
93+
94+
95+
## Proper Nulltermination of Strings (C specific)
96+
97+
## Improper Certificate Validation (CWE 306)
98+
99+
=> Use codyze?
100+
101+
## Use of Hard-coded Credentials (CWE 798)
102+
103+
Idea: when crypto API is known, we could follow to input argument for passwords / keys ...
104+
105+
```
106+
relevant_args = {"function": "arg0"}
107+
forall (n: CallExpression): n.invokes.name in relevant_args.keys => forall u in |backwards_DFG(relevant_args(n.invokes.name))|: u !is Literal
108+
```
109+
110+
## Scribbles
111+
112+
### Test arguments of call expression
113+
```
114+
result.all<CallExpression>({ it.name == "<function name>" }) { it.arguments[<no.>].value!! == const(<value>) }
115+
```
116+
117+
### Track return value of call expression
118+
119+
```
120+
forall (n1: CallExpression, n2: CallExpression): n1.invokes.name == "<function name 1>" && n2.invokes.name == "<function name 2>" => data_flow(n1.returnValue, n2.arguments[<no.>])
121+
```
122+
123+
### Ensure path property
124+
```
125+
forall (n: CallExpression, v: Value) : n.invokes.name == "<function name>" && data_flow(v, n.arguments[<no.>]) => inferred_property(v, <property>)
126+
```
127+
128+
Example:
129+
```
130+
val algo = read_from_file(/* some file */);
131+
if (val != "AES") {
132+
throw Exception();
133+
}
134+
val cipher = initialize_cipher(algo); // at this point one can infer that algo must have the value "AES"
135+
```
136+
137+
## https://cwe.mitre.org/data/definitions/1228.html
138+
139+
Should be easy by simply maintaining a list of the dangerous, inconsistent, obsolete, etc. functions and checking all `CallExpression`s
140+
141+
142+
# Which analyses do we need?
143+
144+
* Integer range
145+
* Buffer size of constant sized arrays (mem size, no elements)
146+
* Data flow analysis (intraproc: DFG edges, interproc: missing)
147+
* Reachability (intraproc: EOG edges, interproc: missing)
148+
* Points-to information
149+
* Taint analysis
150+
* Constant propagation

docs/mkdocs.yaml

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -166,6 +166,7 @@ nav:
166166
- "Evaluation Order Graph (EOG)": CPG/specs/eog.md
167167
- "Implementation":
168168
- CPG/impl/index.md
169+
- "Design Principles": CPG/impl/design_principles.md
169170
- "Language Frontends": CPG/impl/language.md
170171
- "Scopes and Symbols": CPG/impl/scopes.md
171172
- "Passes": CPG/impl/passes.md

0 commit comments

Comments
 (0)