Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve CPIO (and other archive) packer/unpacker pairs using libarchive #397

Open
rbs-jacob opened this issue Dec 14, 2023 · 0 comments
Open

Comments

@rbs-jacob
Copy link
Member

What is the use case for the feature?

In short: replacing some archive packer/unpacker pairs that use command line tools with ones that use libarchive will make those packers more robust.

Currently, some archive packer/unpackers (such as CPIO) are lossy in that the repacked binary is different from the original in critical ways. For example, CPIOs may contain files that must be unpacked to absolute paths. If OFRAK unpacks to absolute paths, it is a security risk – unpacking CPIOs could overwrite critical files (or at least cause permissions errors that make unpacking fail). On the other hand, if OFRAK doesn't unpack to absolute paths, the repacked version will not be repacked with absolute paths, which may cause the repacked file to behave differently when used.

The general solution is to unpack in-memory, instead of to the local filesystem.

Previously, we've tried to address this by using in-memory Python libraries for parsing archive formats. But often, the libraries fail in critical ways that the more robust, battle-tested command-line tools do not. The solution is to use a library for unpacking that is as battle-tested as the command-line tools we're currently relying on. libarchive is such a library, as it is used for bsdtar and bsdcpio that do TAR and CPIO packing/unpacking on macOS and BSD.

How would you implement this feature?

Using the Python ctypes bindings for libarchive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant