Currently, Foreman allows developers to detect build system vulnerabilities by specifying build phase file commands and file permissions, running those phases, and checking that their actual file access behaviors match their specified file permissions.
However, it would be more convenient for developers to be able to detect such vulnerabilities without needing to manually specify their build system phases and permissions.
One way to do this would be to assume from the start that each file only needs to be accessed by one build phase, run the program's build phases, and then simply report any files that were accessed by more than one build phase (and ideally which phases).
Algorithm outline:
- Collect each file status's with calls to
stat().
- Map each file to an empty list.
- For each build phase:
- Run the build phase.
- Repeat step 1.
- If any file's access, modify, or change times were updated during this build phase, then append this build phase to the list of build phases this file is mapped to.
- Sort files by number of build phases they are mapped to.
- Print each file, the number of build phases its mapped to, and the build phases themselves.
Ideally, we would find that most files map to one build phase, and few files map to multiple build phases, and that files that map to multiple build phases indicate build system bugs that present a pipeline poisoning risk (or perhaps existing backdoors).
For further reading, check out this paper, which presents an approach to finding bugs by looking for deviant program behavior.
We would essentially take this concept and apply it to build system file usage behavior: if multiple build phases access the same file, then that is deviant build system behavior, and may indicate a bug.
Currently, Foreman allows developers to detect build system vulnerabilities by specifying build phase file commands and file permissions, running those phases, and checking that their actual file access behaviors match their specified file permissions.
However, it would be more convenient for developers to be able to detect such vulnerabilities without needing to manually specify their build system phases and permissions.
One way to do this would be to assume from the start that each file only needs to be accessed by one build phase, run the program's build phases, and then simply report any files that were accessed by more than one build phase (and ideally which phases).
Algorithm outline:
stat().Ideally, we would find that most files map to one build phase, and few files map to multiple build phases, and that files that map to multiple build phases indicate build system bugs that present a pipeline poisoning risk (or perhaps existing backdoors).
For further reading, check out this paper, which presents an approach to finding bugs by looking for deviant program behavior.
We would essentially take this concept and apply it to build system file usage behavior: if multiple build phases access the same file, then that is deviant build system behavior, and may indicate a bug.