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

[security] Insecure fetching of shared libraries #891

Open
mgorny opened this issue Oct 4, 2022 · 3 comments
Open

[security] Insecure fetching of shared libraries #891

mgorny opened this issue Oct 4, 2022 · 3 comments

Comments

@mgorny
Copy link
Contributor

mgorny commented Oct 4, 2022

imageio can attempt to download shared freeimage libraries from https://github.com/imageio/imageio-binaries/tree/master/freeimage. The code fetches straight from master and provides no way of verifying whether the correct file was fetched. As a result, if the repository is attacked in the future, all prior versions of imageio would be silently downloading arbitrary shared libraries and running them on user systems. This is a serious problem.

@FirefoxMetzger
Copy link
Contributor

FirefoxMetzger commented Oct 4, 2022

Yes, this is indeed an issue and I would like to remove it, too.

My current work towards this end lives here: imageio/imageio-freeimage#3 The idea is to create an optional package that can compile FreeImage on the user's machine with the option to download precompiled binaries (supplied via cibuildwheel). I.e., instead of downloading something that is hard to introspect from a place that might get attacked, we allow the user to download source code and compile it locally.

@FirefoxMetzger
Copy link
Contributor

To keep this thread up to date: For Windows and Linux we now have a working CD pipeline to build FreeImage, so we should be able to switch to a different distribution strategy by the end of the month for these OSes. Since this switch is a breaking change (see some earlier discussion), I will see if we can smooth the transition by going through a deprecation cycle (make switching optional initially) and doing the hard break when we roll over to v3.

For MacOS the situation is a bit more tricky because (a) I don't own an Apple device and (b) the latest FreeImage doesn't build cleanly on MacOS without making changes to the source code. The first issue I might be able to fix [I might be able to borrow a device], and the second issue is conditional on me solving the first. Unfortunately, I can't give a clear ETA for this one since I can't get a good overview of the actual problem. If anyone with a MacOS can tackle this one, it would be highly appreciated :)

@mgorny
Copy link
Contributor Author

mgorny commented Oct 17, 2022

For the record, a quick interim solution (if one is deemed worthwhile) would be to add at least a checksum (sha256 or stronger) verification in the code, and then pin the libraries to a specific git hash.

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

No branches or pull requests

2 participants