Agentic LOTP tool / gadget qualification #111
Conversation
| * If it is a Gadget, discuss its potential role as a "Setup" or "Execution" gadget in a Second-Order attack chain. | ||
| * Reference specific examples or official documentation for the tool to support your conclusion. |
There was a problem hiding this comment.
Not sure about this one. Do we want to describe potential use in Second-Order for a First-Order tool? It seems like noise, since the second-order are defined in the tools which provide second-order vector already?
There was a problem hiding this comment.
Yeah it's kind of confusing.
My idea was it's First-Order if you get a foot-hold (some major or minor) advantage as "Initial Access". Like a First-Order Tool gives you RCE with a sniper shot, while First-Order Gadget gives you something which is constrained, but can be useful to reach a Second-Order Tool in a way. Typically that's gonna be those needing an env var.
| * *Examples:* An XML processor that resolves external entities (`XXE`), a template engine that can include local files. | ||
| * **Arbitrary Network Access:** The ability to make network requests to arbitrary endpoints. This is often used for data exfiltration. | ||
| * *Examples:* A tool with a templating feature that can perform DNS lookups or HTTP requests, an XSLT processor using the `document()` function to fetch a remote DTD or stylesheet. | ||
| * **Environment Variable Manipulation:** The ability to set or modify environment variables for subsequent steps in the pipeline. This is a classic "Setup" primitive. |
There was a problem hiding this comment.
Should we add environment variable read primitive?
There was a problem hiding this comment.
Good point, like it was for Trivy. Reading an env var is not enough, unless you have a way to exfil (via logs or network)
| 1. **The "Setup" Gadget:** A First-Order LOTP that provides a non-RCE primitive, such as writing a file, reading a secret, or setting an environment variable. | ||
| 2. **The "Execution" Gadget:** A subsequent tool in the pipeline that is triggered by the change made by the setup gadget, leading to full RCE. | ||
|
|
||
| A prime example involves `bash` in GitHub Actions. A "setup" gadget (any First-Order LOTP with a file write primitive) could write `BASH_ENV=./attacker-script.sh` to the file at `$GITHUB_ENV`. The "execution" gadget would be `bash` itself in a later `run` step, which would then execute the script because the `BASH_ENV` variable causes `bash` to source the specified script upon startup. For more details on this mechanism, see: [`_tool/bash.md`](_tool/bash.md). |
There was a problem hiding this comment.
I'm not sure it is the best example, since $GITHUB_ENV is a uuid named file, we need to have access to environment variable read to modify this file.
There was a problem hiding this comment.
Yeah, but if I recall at any one time there is a single GITHUB_ENV file or even if many , if you can use * globbing we could affect it without knowing the exact file name, but I agree this has some extra contraints , vs another more static file
|
|
||
| A prime example involves `bash` in GitHub Actions. A "setup" gadget (any First-Order LOTP with a file write primitive) could write `BASH_ENV=./attacker-script.sh` to the file at `$GITHUB_ENV`. The "execution" gadget would be `bash` itself in a later `run` step, which would then execute the script because the `BASH_ENV` variable causes `bash` to source the specified script upon startup. For more details on this mechanism, see: [`_tool/bash.md`](_tool/bash.md). | ||
|
|
||
| It is crucial to understand that while many potential "setup" gadgets exist, they only become exploitable vulnerabilities if a corresponding "execution" gadget exists later in the *same pipeline workflow* to complete the chain. |
There was a problem hiding this comment.
I wonder if it is going to discard LOTP based on this which is workflow dependent.
There was a problem hiding this comment.
Yeah, in terms of the LLM reasoning it should not get stuck on "ame pipeline workflow" too much, more like a rhetorical "imagine a workflow"
Co-authored-by: Sébastien Graveline <[email protected]> Signed-off-by: François Proulx <[email protected]>
Co-authored-by: Sébastien Graveline <[email protected]> Signed-off-by: François Proulx <[email protected]>
2 participants
This pull request introduces a new framework and command for qualifying "Living Off The Pipeline" (LOTP) gadgets in CI/CD security analysis. The main changes include a comprehensive definition of LOTP concepts and attack chains in
GEMINI.md, and the addition of a new.geminicommand for interactive LOTP qualification. These changes provide a structured approach for identifying and classifying pipeline tools and gadgets based on their potential for abuse by attackers.Framework and Definitions for LOTP Analysis:
GEMINI.mdthat defines First-Order and Second-Order LOTP, including clear criteria for identifying malicious primitives (RCE, file read/write, network access, environment variable manipulation) and the importance of verifying the usefulness of those primitives. The documentation also covers the impact of sandboxing and configuration file control on tool security.Interactive LOTP Qualification Command:
.gemini/commands/qualify_lotp.toml, a new command for qualifying a tool as a LOTP gadget. This command guides users through the analysis process, referencing the framework inGEMINI.md, and includes instructions for consulting the knowledge base, analyzing primitives, and determining gadget roles in attack chains.These changes establish a standardized process for evaluating tools within CI/CD pipelines for LOTP risks and enable security experts to document and reason about gadget chains more effectively.