Fraunhofer HHI VVdeC before 3.2.1 contains a heap use-after-free vulnerability in DecLibRecon::createSubPicRefBufs because decompressPicture clears msubPicExtTasks without waiting for pending tasks. Attackers can supply a crafted multi-subpicture VVC bitstream to decoders using two or more threads, causing heap memory corruption or a decoder crash.
Impact
0.31.0 fixed GHSA-6f4g-xm8v-pgv6, where text from a Compose file became GitHub Actions workflow commands in compose-lint's output. The fix escapes the command openers in everything compose-lint prints, and the 0.31.0 changelog says the report "escapes both openers (also covering Azure Pipelines)". Five paths were left open:
- Unicode whitespace before a line-leading ::. The runner strips all Unicode whitespace from the start of a line before it looks for a command. compose-lint only accounted for spaces and tabs, so a no-break space or another Unicode space ahead of :: is not escaped. It can come from a Compose value, or from a file name: the text report's file heading and per-file summary, and the fix summary on stderr, start with the path as given, so a directory named with a leading no-break space followed by :: puts a command at the start of a line. This reaches those lines, the text report's fix guidance, the fix dry-run diff, and continuation lines of stderr diagnostics. - JSON and SARIF printed to stdout. --format json and --format sarif output never passed through the sanitizer, so ##[ inside a service name or other value reaches the log intact when the output isn't redirected to a file. - Command-line errors. When a repository path reaches compose-lint's arguments without a -- before it, the argument parser prints it raw in its error message. That includes a carriage return, which the runner treats as a line break, so a command can also start a new line there. - Azure Pipelines. ##vso[ logging commands were not escaped on any path, despite the changelog's Azure claim. - An error message in the GitHub Action (0.30.0 and 0.31.0). When sarif-file: names a file in a subdirectory that can't be created, the Action prints the directory's resolved path in an error message, outside the window in which it turns command processing off. A pull request can commit a symlink on that path to a directory whose name contains a newline followed by a command. The documented setup, sarif-file: results.sarif at the repository root, is not affected.
A pull request can therefore create annotations, fold or hide parts of the job log, or issue other commands the runner accepts, when CI runs compose-lint over it, before anyone reviews it. The pass/fail result is not changed.
Affected setups are those that print compose-lint's output to a CI log without the GitHub Action: the compose-lint package run directly in a workflow, the pre-commit hook run in CI, and the Docker image. The pre-commit hook is affected in its default configuration: it passes each changed file's path to compose-lint, and a path whose directory name starts with Unicode whitespace and :: reaches the report's file heading. The JSON/SARIF and command-line paths also need output left on stdout, or args: without the documented trailing --, which is why they alone would score lower. The GitHub Action turns command processing off around each compose-lint run, so of these paths only its own error message affects it, and only when sarif-file: points into a subdirectory. That setup is outside the documented one, which is why that path alone would also score lower.
Found during an internal pre-1.0 security review.
Docker image. composelint/compose-lint tag 0.31.0, the matching minor tag, and latest are affected.
Releases before 0.31.0 are covered by GHSA-6f4g-xm8v-pgv6, except the Action's error message, which also affects Action 0.30.0.
Patches
Fixed in 0.32.0. The line-start escaping covers every character the runner strips before ::, so it holds for quoted values and file names alike. JSON and SARIF on stdout escape ##[ inside strings as \u005b, which decodes to the same data. argparse's own messages go through the same sanitizer. ##vso[ is escaped everywhere. In the Action, the SARIF-directory error names the sarif-file: input as written.
Workarounds
- Upgrade to 0.32.0 or later. - On GitHub Actions, use the tmatens/compose-lint Action, or bracket the compose-lint step with ::stop-commands::<random token> and ::<token>::, as the Action does. - In the Action, keep sarif-file at the workspace root, for example sarif-file: results.sarif. - Write --format json and --format sarif output to a file rather than the log. - End the pre-commit hook's args: with --. This closes the command-line path only; it does not stop a file name at the start of a report line, so in CI also bracket the pre-commit step with ::stop-commands:: as above. - On Azure Pipelines, don't print compose-lint's output from runs over untrusted pull requests to the job log.
Reproduction
On compose-lint 0.31.0 on a GitHub-hosted runner (runner 2.337.0), each of the following creates an annotation:
- a Compose file with image: "nginx\n\u00a0::notice::X", linted with the text report; - a directory named \u00a0::notice::X (a no-break space, then ::notice::X) holding a compose.yml, linted with compose-lint -- '<that directory>/compose.yml', or by the pre-commit hook in its default configuration; - a service named a##[warning]X, linted with --format json or --format sarif to stdout; - compose-lint '--##[warning]X/compose.yml' with no --; - the Action with sarif-file: out/reports/results.sarif, where out is a committed symlink to a directory named d\n::warning::X that contains a regular file reports.
The same inputs with a plain space in place of the no-break space, or with -- before the path, or with sarif-file at the repository root, create none. The same inputs on compose-lint 0.30.0 create annotations even with a plain space, which is GHSA-6f4g-xm8v-pgv6. The composelint/compose-lint:0.31.0 image produces byte-identical output to the package.
In removewaiter of rtmutex.c, there is a possible use-after-free due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
Same-origin policy bypass in the Networking: HTTP component. This vulnerability was fixed in Firefox 160, Firefox ESR 115.45, Firefox ESR 153.7, and Thunderbird 160.
Incorrect boundary conditions in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Invalid pointer in the DOM: Editor component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the JavaScript: GC component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Invalid pointer in the Layout: Text and Fonts component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the JavaScript: GC component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the DOM: HTML Parser component. This vulnerability was fixed in Firefox 160, Firefox ESR 115.45, Firefox ESR 153.7, and Thunderbird 160.
Information disclosure in the Address Bar component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the CSS Transitions and Animations component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Invalid pointer in the DOM: Streams component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Privilege escalation due to incorrect boundary conditions in the Graphics: WebRender component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Privilege escalation, sandbox escape due to use-after-free in the Graphics: CanvasWebGL component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Spoofing issue in the DOM: Security component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the DOM: HTML Parser component. This vulnerability was fixed in Firefox 160, Firefox ESR 115.45, Firefox ESR 153.7, and Thunderbird 160.
Invalid pointer in the Networking: Cache component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Incorrect boundary conditions in the DOM: CSS Object Model component. This vulnerability was fixed in Firefox 160, Firefox ESR 115.45, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the CSS Parsing and Computation component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 160, Firefox ESR 115.45, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the Audio/Video component. This vulnerability was fixed in Firefox 160, Firefox ESR 115.45, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the CSS Parsing and Computation component. This vulnerability was fixed in Firefox 160, Firefox ESR 115.45, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the CSS Parsing and Computation component. This vulnerability was fixed in Firefox 160, Firefox ESR 115.45, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the DOM: Workers component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.
Sandbox escape due to incorrect boundary conditions in the Graphics: Text component. This vulnerability was fixed in Firefox 160, Firefox ESR 115.45, Firefox ESR 153.7, and Thunderbird 160.
Use-after-free in the Graphics: Text component. This vulnerability was fixed in Firefox 160, Firefox ESR 115.45, Firefox ESR 153.7, and Thunderbird 160.
Incorrect boundary conditions in the Networking: HTTP component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, and Thunderbird 160.