First the broad one.

Two of the things to consider when evaluating the security of a system are the capability and motivation of the assumed attacker. Most of us are worried about relatively unsophisticated adversaries that don’t actually care that much about us in particular. We want to guard against the cyber-criminal out to get a credit card number, or a telco that wants to sell our info to advertisers. If we’re harder to hack than then next guy, they’ll just move on.

It’s clearly a different case when, for example, law enforcement gets interested in you in specific: the adversary (“The Law”) is now motivated to expend significant, directed effort, and can bring in reasonably sophisticated resources, such as the FBI, to break into your device and messages. If this is your adversary, your job is much harder, and their rate of success goes up substantially.

But we’re talking about people like the Vice President, Secretary of Defense, and Director of National Security: people who would be at the top of any US adversaries’ “to bug” list. The motivation is extreme. And, particularly with Russia and China, we’re talking about highly sophisticated attackers.

And so it is a reasonable assumption that any commodity device, like those running Signal, owned by these individuals have been compromised, and that every conversation they have on them is being scooped up by Beijing and Moscow. For the same reason, it’s a reasonable assumption that their personal laptops, cars, and homes have all been bugged.

This is why the government has separate systems and physical locations to hold this kind of conversation. An isolated, stripped-down, purpose-built system would be much easier to secure than even a minimal Android or iOS device.

We know about this particular case because Mr. Waltz accidentally included Mr. Goldberg on the conversation, leaking the whole thing to The Atlantic. But this was a minor snafu in the grand scheme of things. The big mistake, made by all of the people in the group, was having the conversation on a commodity platform to begin with. And while we know about this particular conversation, we don’t know how many others these individual have broadcast to America’s adversaries.

This was dumb – potentially criminally dumb – behavior by officials who should have known better, and should disqualify all of these individuals from handling classified information in the future.

Beyond this, I think there is a lesson to be learned from the accidental inclusion of Mr. Goldberg on this conversation, and it’s not that Mr. Waltz is an idiot (even if he may be): it’s about user interfaces and Signal’s security model. I don’t know whether Mr. Waltz included the wrong Jeffery Goldberg in the conversation, or just fat-fingered his contacts list, but either way, Signal couldn’t have warned him that what he was doing was dumb, because Signal doesn’t have any notion of an organization or its security boundaries: people are just people.

Indeed, if this group had used Slack for the conversation, or if they were jointly editing a Google Doc, the system would have almost certainly been locked down to avoid the accidental inclusion of any individual outside of the organization. Adding a person from The Atlantic would have at least provided a warning that this was a bad idea, and Mr. Waltz would have almost certainly not made the error.

I’m a fan of (and a donor to) Signal, but the lack of these organizational boundaries is a good argument against its organizational use. And I suspect that for Signal, this is just fine: that’s not the use case they’re targeting.

In this post we’ll explore a common way to implement row-level security on top of a relational database and see why it may not be as secure as it looks.

A Pop Quiz

But before we get to the crux of the issue, here’s a quick quiz. I promise it’s relevant.

What will each of the following languages do when a is equal to 0​?

1. C, C++, C#, Java, and most other C-family languages:
   if (a != 0 && 1/a > 0) { /* Do something */ }
2. Pascal:
   IF a <> 0 AND 1/a > 0 THEN (* Do something *)
3. SQL:
   SELECT *
FROM T
WHERE a <> 0 AND 1/a > 0

Obviously, I’m asking about short circuiting behavior. I’ll let you ponder and reveal the answers in a moment. But first, back to row-level security.

The Setup

Imagine that we have a table of sensitive customer information:

customers:
id  ssn        balance
--- ---------- --------
1   123456789  150.00
2   234567890  250.00
3   345678901  350.00
4   456789012  450.00
5   567890123  550.00
6   678901234  650.00
7   789012345  750.00
8   890123456  850.00
9   901234567  950.00

(Apologies if I’ve exposed your SSN…)

We want to provide our employees access, but only to their customers, not the entire set.

A common way to do this on a system that doesn’t have built-in row-level security is to (a) add a security table that expresses which rows each user is allowed to see, (b) build a view that uses this security table to restrict the rows that each user sees, and (c) force everyone to access the data through the view.

So, I first create a security table that maps users to the customers they can see. E.g.,:

access:
uid    cid
------ -----
alice  1
alice  2
alice  3
isaac  4
isaac  5
isaac  6
bob    7
bob    8
bob    9

This means, e.g., that isaac should only be able to see customers numbered 4, 5, and 6. To enforce this we create a view:

CREATE VIEW sec_customers
AS
SELECT *
FROM CUSTOMERS
WHERE id IN 
    (SELECT cid FROM access WHERE uid = USER_NAME())

I’m showing this with SQL Server, so I’m using the built-in function USER_NAME() to dynamically modify the query based on the user who accesses the view. The specifics here will vary system-to-system, but you should be able to accomplish something similar.

We’ll restrict access to the base table, and let users only come in through the view. Now when isaac selects everything from sec_customers, all he sees is:

id  ssn        balance
--- ---------- --------
4   456789012  450.00
5   567890123  550.00
6   678901234  650.00

The Punchline

Pretty good! But before we celebrate, let’s look at the answers to our quiz:

1. In most C-family languages, compound predicates like this short circuit: the system will check whether a != 0 and only execute the 1/a > 0 bit if a isn’t zero. The body of our conditional won’t be executed, but life will go on as usual.
2. In Pascal there is no short circuiting: the system will always execute all of the parts of the compound predicate. So if a is zero, the system will throw a divide-by-zero error.
3. In a particularly awesome twist of semantics, SQL short circuits but doesn’t guarantee order of operations. So this code may execute fine if it tests a <> 0 first, or it may throw an exception if it tries the division first—you’re at the whim of the optimizer.

What does this have to do with row-level security? As I mentioned when discussing extract types in Tableau, when you write a query against a (virtual) view in SQL, your query is composed with the view query, and this whole thing is then optimized. But SQL doesn’t generally respect the order of the operations you’ve written down, and this disregard runs deep. There is no “query boundary” when you compose queries: your operations can get shuffled around anywhere in the plan.

And that’s a problem when it comes to security.

To illustrate, let’s try another query against my “secured” customer table. I’m going to guess the Social Security number of a customer that I shouldn’t have access to, and see what I can find with a little SQL.

If I guess incorrectly, everything works as we’d expect:

SELECT *
FROM sec_customers
WHERE 1/(ssn - 789012346) = 0

id  ssn        balance
--- ---------- --------
4   456789012   450.00
5   567890123   550.00
6   678901234   650.00

But if I guess correctly:

SELECT *
FROM sec_customers
WHERE id = 7 AND 1/(ssn - 789012345) = 0

id  ssn        balance
--- ---------- --------
4   456789012  450.00
5   567890123  550.00
6   678901234  650.00
Msg 8134, Level 16, State 1, Line 16
Divide by zero error encountered.

And now I know that a customer has an SSN of 789012345: I’ve leaked information that I shouldn’t have leaked. And with a little work, I may be able to narrow this down to a particular customer.

What happened? Looking at the query plan for this query it becomes more clear:

The syntax implies that customers I don’t have access to will be filtered out before they hit my query. But the optimizer has reordered the operations: the security filter is enforced by the join, and my predicate has been “pushed down” and folded into the table scan. The result is that the predicate sees the entire customer table, which results in an information-leaking exception.

Coda

I’ve shown this with SQL Server, but this isn’t a criticism of that system. Aside from the specifics around identifying the user, the mechanism I’ve shown is likely to apply to any database with an optimizer that can rearrange operations—which is to say any database worth it’s salt.

That said, while SQL Server did add first-class row-level security in SQL Server 2016, it’s likely that it’s using a similar mechanism under the hood. As Microsoft’s notes:

Carefully crafted queries: It is possible to cause information leakage through the use of carefully crafted queries. For example, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe' would let a malicious user know that John Doe’s salary is $100,000. Even though there is a security predicate in place to prevent a malicious user from directly querying other people’s salary, the user can determine when the query returns a divide-by-zero exception.

Is this a worry? Well, I suppose it depends. But I’d be reluctant to rely on this mechanism if I had a real concern about exposing data.