Security Issues With Using Package Managers
What are these issues, and what to do about them?
A package manager or package management system is a collection of software tools that automate the process of installing, upgrading, configuring, and removing computer programs for a computer’s operating system in a consistent manner. However, these can have their own security flaws as well. It is common for users to use package managers to stay up-to-date in terms of software without understanding the implications it could have. Since a package manager runs as root and poor implementation of it can mean downloading and installing malicious software onto your system. I’m sure no one would want that.
I will be telling you about the different attacks that can happen through package managers, and what you can do about it.
How do these attacks take place?
There are essentially two main ways an attacker can use — metadata replay and mirror control. The underlying method in both these ways is that instead of a legitimate repository of distribution responding to the client when a packaging manager downloads files, an attacker does this job.
Metadata replay means the attacker can send you packages that are old and were signed and have vulnerabilities. The main problem is that once the root metadata is signed, the client’s system will trust it even if there are some flaws. An attacker can easily exploit these flaws and do malicious things with your system.
Mirror control is the easiest way for an attacker to become the middle man. Most distributions use a network of publicly provided servers that are used to host their mirrors. It is too easy for any person to become validated as a mirror.
In a study in 2009 by Justin Samuel from the University of Arizona, he ran an experiment where he created a fake administrator and company name and leased a server from a hosting provider. He was able to get his mirror listed on every distribution we tried (Ubuntu, Fedora, OpenSuSE, CentOS, and Debian) and his mirrors were contacted by thousands of clients, even including military and government computers!
This proves how much verification is required to have mirror control. There’s no guarantee who you might be speaking to, it can be an attacker who has become an official mirror for distribution.
What impact can this have?
A replay attack boils down to the fact that a client requests root metadata and the malicious mirror responds with old signed files. The malicious party only needs a copy of the old signed files and this can be done without compromising the signing key. The client only knows that they received a package of signed files from distribution, they’re not aware of whether the files are old or not. The signing key has the main role here- once a package is signed, a client will trust it regardless of the vulnerabilities present in it. All the attacker needs to do is send the package with such vulnerabilities that they can exploit.
In addition to this, if an attacker has the chance to manipulate metadata, he can also lie to the clients about what a package requires. If a package has a vulnerability the attacker knows how to exploit, he can provide metadata that says every package depends on this package. This ensures that the client installs it when installing any other package. Only a user with intimate knowledge of the packages and their dependencies will spot this.
How to overcome these issues?
Thankfully, we’ve found these problems earlier and there are definitely ways to overcome these and not get trapped by a hostile hacker. There are several things that Justin has told us we can do to avoid this situation -
Use repositories you trust
Use only mirrors that belong to reputable organizations. Don’t randomly choose mirrors, even from official lists. The official lists of public repositories often contain many superficially verified mirrors.
Manually update your systems (and local mirror caches)
Know when package updates become available and what the versions should be. Manually verify and install the updated packages (or add them to your local mirror cache that your systems update from) rather than relying on automated updates. We have observed mirrors many months out of date for some distributions, so you should check periodically that your mirror is being updated.
He mentions that these are only short term solutions and for the future —
Use package managers that implement metadata expiration.
If there is no way in a package manager for metadata to ever expire, replay attacks will be able to go unnoticed.
Use distributions that properly make use of the package manager’s security features
If a distribution doesn’t sign repository metadata or expire these signed files even though the package manager supports doing so, it doesn’t help you stay secure.
Conclusion
Although these problems were discovered back in 2009 which seem like way back when they still exist in today’s world. However, according to Ludwig Nussel from the openSUSE security team, these are fixed.
One can only hope and if they haven’t been fixed yet, you should be glad that you’ve read this article because now you at least know that such a problem exists.
Thank You for Reading!
Found this post useful? Kindly hit the 👏 button below to show how much you liked this post!
Inheaden is a young IT and software startup based in Darmstadt, Germany. As an “Idea and Tech Factory”, we have set out to be a driving force of innovation, digitization, and automation with a focus on the areas of services, products, and research. Under the Inheaden brand, we work on individual “high performance” software solutions that bring a change. Modern designs, innovative technology approaches, and IT security for our partners and customers are important components of our work profile.
