This document describes subsystems which need special consideration during security bug classification. For the overall process, see Security Process.

Regular expression processing

Regular expression processing comes in two parts, compilation (through regcomp) and execution (through regexec).

Implementing regular expressions efficiently, in a standard-conforming way, and without denial-of-service vulnerabilities is very difficult and impossible for Basic Regular Expressions. Most implementation strategies have issues dealing with certain classes of patterns.

Consequently, resource exhaustion issues which can be triggered only with crafted patterns (either during compilation or execution) are not treated as security bugs. (This does not mean we do not intend to fix such issues as regular bugs if possible.)

However, during execution, crashes, infinite loops, buffer overflows and reading past buffers (read-only buffer overruns), memory leaks and other, similar bugs should be treated as security vulnerabilities, assuming that the pattern is trusted and reasonably structured.

wordexp patterns

wordexp inherently has exponential memory consumption in terms of the input size. This means that denial of service flaws from crafted patterns are not security issues (even if they lead to other issues, such as NULL pointer dereferences).

Asynchronous I/O

The GNU C Library tries to implement asynchronous I/O without kernel support, which means that several operations are not fully standard conforming. Several known races can cause crashes and resource leaks. Such bugs are only treated as security bugs if applications (as opposed to synthetic test cases) have security exposures due to these bugs.

Asynchronous cancellation

The implementation of asynchronous cancellation is not fully standard-conforming and has races and leaks. Again, such bugs are only treated as security bugs if applications (as opposed to synthetic test cases) have security exposures due to these bugs.

Post-exploitation countermeasures

Certain features have been added to the library only to make exploitation of security bugs (mainly for code execution) more difficult. Examples includes the stack smashing protector, function pointer obfuscation, vtable validation for stdio stream handles, and various heap consistency checks. Failure of such countermeasures to stop exploitation of a different vulnerability is not a security vulnerability in itself. By their nature, these countermeasures are based on heuristics and will never offer complete protection, so the original vulnerability needs to be fixed anyway.

None: Security Exceptions (last edited 2019-02-02 14:27:50 by FlorianWeimer)