Using Vulnerable Libraries

Fixing Vulnerable Libraries

About Vulnerable Libraries

What are Vulnerable Libraries?

Vulnerable libraries are software components or modules that contain known security vulnerabilities that can be exploited by attackers. Libraries are typically pre-written code that is designed to perform specific functions or tasks and can be used by developers to build their own applications.

Vulnerable libraries can be introduced in various ways, such as outdated or unsupported libraries, libraries with known security issues, or libraries that have been modified by third-party developers.

Check out this video for a high-level explanation:

What is the impact of Vulnerable Libraries?

Vulnerable Libraries can contain any kind of vulnerability, ranging from moderate to critical risk. In some cases, these vulnerabilities are easily exploitable, even through automation, such as Log4Shell (CVE-2021-44228). This can result in immediate compromise of the application.

A list of the Top 15 Routinely Exploited Vulnerabilities in 2021 can be seen here.

How to prevent Vulnerable Libraries?

To prevent the use of vulnerable libraries, it is important to follow security best practices and implement appropriate security measures, such as:

• Use up-to-date and supported libraries: Use up-to-date and supported libraries that have been tested for security vulnerabilities and have been updated with security patches.
• Regularly scan and test libraries: Regularly scan and test libraries for known vulnerabilities, using automated tools and services to identify potential security issues and vulnerabilities.
• Conduct regular security audits: Conduct regular security audits and code reviews to identify and address potential security issues and vulnerabilities.
• Monitor alerts and notifications: Monitor alerts and notifications from security vendors and industry groups about potential security risks and vulnerabilities in libraries and other software components.

Ideally, the patch management process ensures that updates are installed on an ongoing basis, to avoid having to install major version updates. Automated test suites can help verify that the application is still working the way it is intended after an upgrade.

References

Taxonomies

• OWASP Top 10 - A06 Vulnerable and Outdated Components
• CWE-1104: Use of Unmaintained Third Party Components

Training

• Secure Code Warrior: Vulnerable Components

Option A: Update the library

1. Look at the vulnerable package in the GuardRails PR comment

2. Identify if a fixed version is available and your Gemfile doesn't have conflicting constraints

   # Resolve constraint that prevent updating to a fixed version
   # For example, this would prevent you from upgrading to Rails 5.2.0
   gem 'rails', '~> 5.1.6'

3. Once you know that the update can be done, run the according command:

   # Attempt a patch-level only (--patch) update to the Gemfile.lock
   # with as minimal effect on other gems as possible
   bundle update --patch --conservative <vulnerable-gem-name>
   # Update gems to latest minor version
   bundle update --minor --strict
   # Update gems to latest major version
   bundle update --major

4. Test to verify that the upgrade doesn't break the app

5. Ship it 🚢 and relax 🌴

Option B: When no update is available

1. Look at the vulnerable package in the GuardRails PR comment
2. If no update is available then you have 3 choices:
   • Remove the package if it's not needed
   • Replace the package with another one that doesn't contain vulnerabilities
   • Take a closer look at the vulnerability details and create a PR patching it
3. Test to verify that your actions don't break the app
4. Ship it 🚢 and relax 🌴