Vulnerable library used doesn’t have a fix — how?
Hello 👋 technical folks ~
Open-source software/library isn’t foreign to most of us today; it’s estimated that the open-source software forms about 70–90% of any piece of modern software today. Just in 2021 alone, cybercrime cost an estimated $6 trillion worldwide (read here).
As we all know, all information of any open-source software/library (even forum discussions among all software engineers worldwide) is public. This means that attackers will also be able to gain access to all this information. Thus, there’s no reason for us not to address any vulnerabilities found, even in the very earlier stage of development!
Yes, we totally understand your struggles and frustrations! There’s lots of dependencies for any open-source projects — it depends on whether the library contributor wants to fix it or not and/or when s/he will release the fix. Here are some steps you can take:
Explanations:
Step 1: Check if this library is still in use within your codebase
If the library is no longer in use within the codebase, remove it!
Step 2: Check if there’s any available patch
Once you’ve confirmed the library is being used, the next thing to do is to check if there’s any available patch. If there’s an available patch, upgrade it! Otherwise, check the library in the contributor’s Github; most likely there will be at least one person who has raised this issue to the contributor and/or there’s discussion about this issue.
Find out what the contributor says. Sometimes s/he may not want to fix the issue, then maybe it’s time to re-evaluate the possibility of switching to another similar library. If not, we’ll be like the image above! 😂
Step 3: Check if the library’s version is reported to have the vulnerability
If the version you’re using is different from the affected version or it doesn’t fall within the affected version range, then there’s no action required on your end. For instance, the SSRF vulnerability only occurs in parse-url versions before 6.0.1. So if you’re using version 6.0.1 or later, you’re not affected.
Step 4: Check if the library’s affected function(s) is used in your system
Not everything about the vulnerable library is affected; find out what’s the affected portion and you may realise that it isn’t used in your codebase. In the case of the parse-url library, the only function affected is parseUrl().
If the affected function(s) is used in your code, go to step 5. Otherwise, go to step 6.
Step 5: Check that there’s mitigation(s) in place before calling the affected function(s)
If you’re calling the affected function(s) directly in your code, think of all possible security loopholes based on the vulnerability raised. Once you’ve come out with a list of potential loopholes, implement the necessary (interim) mitigation(s) before calling those function(s).
After the mitigations are set in place, add this vulnerable library into your team’s Risk Register, continue to monitor, and update the library when there’s a fix.
Step 6: Check if library’s affected function(s) is used by the function(s) you’re calling in your code
A library consists of more than one function and they are there for a purpose. If you’re not calling those affected function(s) in your code, most likely they’re being called internally within the library by its other functions.
If the function(s) you’re using isn’t calling those affected function(s), then you are considered quite safe. Otherwise, repeat the steps mentioned in Step 5.
Preventing cybercrime is on the mind of every business, and with more adoption of open-source software to speed up development work, there should be no excuse when it comes to addressing security vulnerabilities.
With this article, we hope that you’ve learned how to determine if there’s a fix required on your end when there’s a vulnerability. If a fix is needed but there are no solutions, always remember to set the necessary mitigation(s) before calling those function(s), track it in your team’s Risk Register, continue to monitor, and update the library when there’s a fix.
🧙🏼♀Team Merlin 💛
Application security is not any individual’s problem but a shared responsibility.
