Critical SQL Injection flaws in Gentoo Soko can lead to Remote Code Execution

SQL injection vulnerabilities in Gentoo Soko could lead to remote code execution (RCE) on impacted systems.

SonarSource researchers discovered two SQL injection vulnerabilities in Gentoo Soko, collectively tracked as CVE-2023-28424 (CVSS score: 9.1) [1],[2], that can be exploited by a remote attacker to execute arbitrary code on vulnerable systems.

“The two package search handlers, Search and SearchFeed, implemented in pkg/app/handler/packages/search.go, are affected by a SQL injection via the q parameter. As a result, unauthenticated attackers can execute arbitrary SQL queries on https://packages.gentoo.org/.” reads the advisory published on GitHub. “It was also demonstrated that primitive was enough to gain code execution in the context of the PostgreSQL container.”

“The GraphiQL resolver PackageSearch, implemented in pkg/api/graphql/resolvers/resolver.go, is affected by a SQL injection via the searchTerm parameter. As a result, unauthenticated attackers can execute arbitrary SQL queries on https://packages.gentoo.org/.” states the advisory. “It was also demonstrated that primitive was enough to gain code execution in the context of the PostgreSQL container.”

Soko is a software deployed in the Gentoo Linux infrastructure, the researchers pointed out that is possible to exploit the issue to carry out SQL injection attacks despite the use of an Object-Relational Mapping (ORM) library and prepared statements.

The researchers explained that the exploitation of the vulnerabilities is possible due to a misconfiguration of the database.

The misconfiguration likely comes from the Docker containerization of their database, the experts pointed out that containers often “enjoy elevated privileges” because they are seen as a security boundary between software components.

SonarSource’s report states that a threat actor can inject specially crafted code to circumvent the escaping feature in the module to compose the queries and introduce SQL injections, resulting in the exposure of sensitive data.

The researchers recommend development teams of understanding how ORM APIs are designed to avoid the exploitation of similar vulnerabilities. 

“In general, a common source of vulnerabilities with ORMs happens when there is no reference to the query builder instance in the current context; such cases are usually methods made to avoid code duplication across queries. Developers are then more likely to craft parts of the query manually and introduce SQL injections.” concludes the report. “Additionally, every ORM comes with its own take on API design, and it can be tricky to know about unsafe code patterns at first sight. This is where Go’s typing could come in handy at the cost of some flexibility by introducing compile-time safeguards, forcing developers to always separate instructions (the prepared statement) from data (the user’s input).”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Gentoo Soko)