Database Data Protected By Row-Level Security Can Be Revealed by Analyzing Query Execution Times

What is it about?

Many databases systems are used by several different entities or users, referred to as "tenants." Tenants aren't supposed to be able to see each others data. A popular mechanism for the database to control who sees what is called row-level security (RLS). RLS enables specifying per-row access controls, which the database enforces by rewriting tenant queries to add an "RLS policy filter" that filters out rows the tenant is not allowed to view. Unfortunately, while RLS blocks queries from returning unauthorized data, there are additional aspects of how queries execute (except for their output) that can be exploited to reveal data stored in protected rows. Such exploits are called "side-channels attacks." This paper looks into how the time it takes to query an RLS-protected database can give away secrets stored in the database. We found that in in PostgreSQL and SQL Server, a clever attacker can figure out if a specific value exists in the rows they're not authorized to view. In some cases, they can figure out how many times such a value exists in the table. Our attack is practical and succeeds in a realistic cloud setting: we successfully attack managed PostgreSQL and SQL Server database instances on AWS from virtual machines in the same and different data centers. We also describe how database systems can mitigate the attacks under certain conditions, and the security vs. performance trade-offs involved.

Featured Image

Photo by Markus Spiske on Unsplash

Photo by Markus Spiske on Unsplash

Why is it important?

Database systems are used to store a lot of sensitive information. Row-level security is a popular mechanism for protecting such information. It's therefore vital to understand the limitations of RLS and how even when data is protected by RLS, certain information about it can still be inferred by attackers. Our work can help guide system designers and database administrators to make more informed decisions about how to protect their data.