软件安全备忘录：Mem Management

1. risk assessment

CERT C Coding Standard contains a risk assessment section

1.1. Severity 严重性

• How serious are the consequences of the rule being ignored

Value	Meaning	Examples of Vulnerabilities
1	low	Denial-of-service attack, abnormal termination
2	medium	Data integrity violation, unintentional information disclosure
3	high	Run arbitrary code

1.2. Likelihood 可能性

• How likely is it that a flaw introduced by ignoring the rule can lead to an exploitable vulnerability

Value	Meaning
1	Unlikely
2	Probable
3	likely

1.3. Detection and Correction 检测和纠正

• How will we cope with detection and correction

Value	Meaning	Detection	Correction
1	low	Automatic(Static and Dynamic Analysis)	Automatic(Fault Localisation and Repair)
2	medium	Automatic(Static and Dynamic Analysis)	Manual
3	high	Manual(Code Inspection)	Manual

1.4. Risk Management

• The three values are then multiplied together for each rule: severity, likelihood and remediation cost
  • 10 distinct values are possible: 1, 2, 3, 4, 6, 8, 9, 12, 18, and 27
• priority range
  • 12 to 27 are Level 1
  • 6 to 9 are Level 2
  • 1 to 4 are Level 3

2. CERT C Coding Standard

2.1. MEM30-C. Do not access freed memory

dangling pointers悬空指针

• Pointers to memory that has been deallocated
  • Accessing a dangling pointer is undefined behaviour and can result in exploitable vulnerabilities

example

• p is freed before p->next is executed, so that p->next reads memory that has already been freed

Risk Assessment

• Reading memory that has been freed
  • abnormal program termination
  • denial-of-service attacks
• Writing memory
  • execution of arbitrary code

2.2. MEM31-C. Free dynamically allocated memory when no longer needed

example

• The object allocated by the call to malloc() is not freed before the end of the lifetime of the last pointer

2.3. MEM33-C. Allocate and copy structures containing a flexible array member dynamically

As a special case, the last element of a structure with more than one named member may have an incomplete array type; this is called a flexible array member. In most situations, the flexible array member is ignored. In particular, the size of the structure is as if the flexible array member were omitted except that it may have more trailing padding than the omission would imply.

example

2.4. MEM34-C. Only free memory allocated dynamically

• Freeing memory that is not allocated dynamically can result in heap corruption

Risk Assessment

• The consequences of this error depend on the implementation
  • they range from nothing to arbitrary code execution if that memory is reused by malloc()

2.5. MEM35-C. Allocate sufficient memory for an object

• An insufficient amount of memory can be allocated where sizeof(long) is larger than sizeof(int), which can cause a heap buffer overflow

example

2.6. MEM36-C. Do not modify the alignment of objects by calling realloc()

• Do not invoke realloc() to modify the size of allocated objects that have stricter alignment requirements than those guaranteed by malloc()

3. Secure C Programming

1. Pointers should not be left uninitialized
2. They should be assigned either NULL or the address of a valid item in memory
3. When you use free to deallocate dynamically allocated memory, the pointer passed to free is not assigned a new value, so it still points to the memory location where the dynamically allocated memory used to be
4. When you free dynamically allocated memory, you should immediately assign the pointer either NULL or a valid address
   1. We chose not to do this for local pointer variables that immediately go out of scope after a call to free
5. Undefined behavior occurs when you attempt to use free to deallocate dynamic memory that was already deallocated—this is known as a “double free vulnerability”
6. To ensure that you don’t attempt to deallocate the same memory more than once, immediately set a pointer to NULL after the call to free— attempting to free a NULL pointer has no effect
7. Function malloc returns NULL if it’s unable to allocate the requested memory
8. You should always ensure that malloc did not return NULL before attempting to use the pointer that stores malloc’s return value

4. Tool Selection and Validation

Although rule checking can be performed manually, with increasing program size and complexity, it rapidly becomes infeasible. For this reason, the use of static analysis tools is recommended

When choosing a source code analysis tool, it is clearly desirable that the tool be able to enforce as many of the guidelines on the wiki as possible

4.1. Completeness and Soundness

It should be recognized that, in general, determining conformance to coding rules and recommendations is computationally undecidable. The precision of static analysis has practical limitations.

• 应该认识到，一般来说，确定是否符合编码规则和建议在计算上是无法决定的。静态分析的精确性有实际的限制。

For example, the halting theorem of computer science states that programs exist in which exact control flow cannot be determined statically. Consequently, any property dependent on control flow—such as halting—may be indeterminate for some programs. A consequence of undecidability is that it may be impossible for any tool to determine statically whether a given guideline is satisfied in specific circumstances. The widespread presence of such code may also lead to unexpected results from an analysis tool.

• the analysis may generate:
  • Flase negatives
  • Flase positive

• An analyzer is considered sound with respect to a specific guideline if it cannot give a false-negative result, meaning it finds all violations of the guideline within the entire program
• An analyzer is considered complete if it cannot issue false-positive results, or false alarms
• incomplete:
  • You cannot prove everything that in the system is True
  • There are some assertion cannot be triggered.

4.1.1. False Negatives

Failure to report a real flaw in the code is usually regarded as the most serious analysis error, as it may leave the user with a false sense of security. Most tools err on the side of caution and consequently generate false positives.

4.1.2. False Positives

The tool reports a flaw when one does not exist. False positives may occur because the code is too complex for the tool to perform a complete analysis. The use of features such as function pointers and libraries may make false positives more likely

4.2. Taint Analysis 污点分析

• If the value of an operand or argument may be outside the domain of an operation or function that consumes that value, and the value is derived from any external input to the program (such as a command-line argument, data returned from a system call, or data in shared memory), that value is tainted, and its origin is known as a tainted source.

4.2.1. Sanitization

To remove the taint from a value, the value must be sanitized to ensure that it is in the defined domain of any restricted sink into which it flows.

• Operands and arguments whose domain is a subset of the domain described by their types are called restricted sinks. Any integer operand used in a pointer arithmetic operation is a restricted sink for that operand
  • 比如数组越界就算out of domain?

更多参考

• AddressSanitizer — Clang 15.0.0git documentation