Late last week, Tencent announced that researchers from its Blade Team had discovered a remote code execution (RCE) vulnerability in SQLite, dubbed Magellan. SQLite is a very popular embedded SQL server. It is one of the components inside many thousands of applications, including the Google Chromium browser. Google has since updated Chromium to contain the fixed version of SQLite, version 3.26.0, released on December 1. Although there are no reports of the vulnerability being executed in the wild, a situation where a high-impact vulnerability is found in a component that is in widespread use is usually a cause for alarm. This case, however, has some mitigating circumstances that will keep this from being another Heartbleed-size problem.
As discussed in previous posts, when we look at vulnerabilities in open source components, we need to distinguish between a component that contains a vulnerability and how that component is used by an application. Every development team that embedded SQLite needs to be doing this right now. It turns out that for an attacker to exploit this particular vulnerability in an application, they need to be able to manipulate queries that the application makes to SQLite. Chromium implements Web SQL, which allows an attacker to create a web page that will send SQL commands to the embedded SQLite code – thus making it vulnerable. If your application allows user input to construct SQL queries, then your application is likely vulnerable, too.
There are other situations where your application may be vulnerable. Allowing attackers to construct SQL queries sounds a lot like a SQL injection vulnerability. If your app does have a SQLi vulnerability, you may now have a bigger problem with a far more serious RCE vulnerability if you’re using an outdated version of SQLite. If you’re using application security testing techniques, including SAST, DAST, and manual penetration testing and fixing issues found as a part of your development process, you may feel confident that your apps don’t have any SQLi vulnerabilities. Whether or not you have an AppSec program in place, the best thing that development teams can do is update to the latest version of SQLite.
This is true any time you determine that your application uses a component with a known vulnerability, and updating does not need to be a fire drill. Software composition analysis (SCA) can look at the open source code in your app and tell you if there are known vulnerabilities and if a vulnerable method is being called. Veracode’s SCA product uses control flow analysis to do this quickly, without a manual inspection of the components in use. If you find that your application or applications are not vulnerable, you can wait until there is a convenient time to update the component so that keeping current isn’t disruptive to your development schedule.
To learn more about how Veracode can help mitigate your organization’s open source risk, download our whitepaper: https://info.veracode.com/whitepaper-solving-your-open-source-risk-with-sourceclear.html