Skip to content

v1.0.6

Latest
Latest
Compare
Choose a tag to compare
@cgwalters cgwalters released this 16 Sep 12:57
· 19 commits to main since this release
v1.0.6
2b6560e
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.

Feature: mkcomposefs --from-file fuzzing

A while ago while working on the Rust composefs bindings I found a bug in the dumpfile parser where the process would crash if provided an unexpected value.

Today for the Rust bindings and the containers/image library because we're forking off a separate process (that we can apply isolation to and low privilege overall) even an assertion failure is relatively benign. And such tools usually wouldn't produce a dumpfile malformed in that way. But still, it caused me to question whether there were other bugs.

For codebases that are linking in the libcomposefs library, process aborts are obviously more problematic.

This series is the result of running honggfuzz and quite a lot of time spent learning this codebase.

Thanks to @hsiangkao @alexlarsson @jeckersb @giuseppe @allisonkarlitskaya for their assistance with reviews and discussion of this!

Composefs and security

I don't think there's cause to classify this as a CVE yet, as we didn't really formally declare that mkcomposefs --from-file is a "security boundary". At the current time, if you are using composefs in a context where it is being provided potentially malicious input, it is strongly recommended to ensure that the input is validated and sanitized as much as possible, alongside use of hardening and fuzzing techniques. We have developed Rust bindings for example which do some of this, and work will continue on that.

This said, we will likely aim to make "mkcomposefs --from-file" a security boundary in the future (e.g. guaranteeing that it will always either return an error or generate a valid EROFS) and allocate CVEs for any further flaws.

Composefs and reliability

composefs has been used reliably in many cases for a while now; in general almost all of these issues could only occur for extreme boundary conditions such as:

  • symlinks close to the PATH_MAX (4096 byte) limit
  • extremely large extended attributes
  • Files claiming to be extremely large (> 5 EiB)

Hence, I do not think there is a need for existing composefs users to consider this a critical fix.

Most of these cases also again would fail with an assertion - at most a denial of service. However in some cases we would produce a corrupted EROFS blob - and in the cases I tested, the Linux kernel EROFS parser successfully detected the corruption.

The EROFS kernel code is actively fuzzed and fixed when bugs are found (e.g. this recent one) but still a goal for this project is to avoid exposing the Linux kernel code to a potentially corrupted EROFS at all.

(A core part of the idea of composefs is that the EROFS metadata doesn't need to be transported "on the wire", it can be re-synthesized reproducibly from other metadata, such as existing OCI tar layers, or ostree commits, etc.)

Autotools build system dropped

The only supported build system is now meson.

Potentially incompatible changes

  • mkcomposefs: Process last content in dumpfile without newline by @cgwalters in #331

We believe this is unlikely to break anyone, but if it does we are open to reverting this change.

New features

Other changes

New Contributors

Full Changelog: v1.0.5...v1.0.6

Contributors

jeckersb, cgwalters, and 2 other contributors
Assets 3
Loading