SQL Injection Bypass in Langroid SQLChatAgent

Executive Summary

The vulnerability affects the SQLChatAgent component in the langroid package (versions up to 0.65.0). It involves a bypass of the SQL injection mitigation that relies on a regex blocklist to detect dangerous PostgreSQL function calls like pg_read_file.

The regex pattern checks for function names immediately followed by a parenthesis, but PostgreSQL allows calling functions with the name separated from the parenthesis by quoted identifiers, inline comments, or schema qualifications. These forms evade the regex check.

As a result, attackers who can influence the SQL generated by the large language model can bypass the safety policy and execute dangerous functions such as pg_read_file, which can read server-side files if the PostgreSQL role has sufficient privileges.

The root cause is that the validation uses raw-text regex matching instead of analyzing the normalized Abstract Syntax Tree (AST) of the SQL statement, allowing these bypasses.

Version 0.65.1 of langroid fixes this issue by addressing the bypass.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can allow an attacker who can influence the SQL generated by the large language model to bypass SQL injection protections and execute dangerous PostgreSQL functions.

Specifically, it enables reading server-side files using the pg_read_file function, which can expose sensitive data stored on the database server.

The impact depends on the privileges of the PostgreSQL role used by the application; if it has superuser or pg_read_server_files privileges, the attacker can access critical files.

This can lead to data breaches, exposure of confidential information, and compromise of the server environment.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by monitoring for SQL queries that invoke dangerous PostgreSQL functions like pg_read_file using evasion techniques such as quoted identifiers, inline comments, or schema qualification.

Examples of suspicious queries to look for include:

• SELECT "pg_read_file"('/etc/passwd')
• SELECT pg_read_file/**/('/etc/passwd')
• SELECT pg_catalog."pg_read_file"('/etc/passwd')

To detect such queries on your system or network, you can use database query logging or network packet inspection tools to filter for SQL statements containing these patterns.

For example, on PostgreSQL, enable query logging with:

• ALTER SYSTEM SET log_statement = 'all';
• SELECT pg_reload_conf();

Then search the logs for occurrences of pg_read_file with unusual syntax, such as using regex or grep commands:

• grep -E 'pg_read_file|"pg_read_file"|pg_read_file/\*\*/' /var/log/postgresql/postgresql.log

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation is to upgrade the langroid package to version 0.65.1 or later, where this vulnerability is fixed.

Until the upgrade can be applied, consider restricting the PostgreSQL roles that have the ability to execute dangerous functions like pg_read_file, limiting privileges such as superuser or pg_read_server_files.

Additionally, review and harden any SQL generation or execution logic in your applications that use the SQLChatAgent component to avoid allowing user input to influence SQL queries without proper validation.

Long term, replacing regex-based dangerous function detection with AST-based validation after SQL parsing is recommended to prevent bypasses.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability allows attackers to bypass SQL injection mitigations and execute dangerous PostgreSQL functions such as pg_read_file, enabling unauthorized server-side file reads. This can lead to exposure of sensitive data stored on the server.

Such unauthorized data access and potential data breaches can negatively impact compliance with data protection regulations like GDPR and HIPAA, which require strict controls to protect personal and sensitive information from unauthorized access.

Therefore, if exploited, this vulnerability could result in violations of these standards due to failure to adequately protect sensitive data.

Useful 0 Not Useful 0