Does Serializable isolation level protect databases against ACIDRain attack?

Question

ACIDRain attack paper by Todd Warszawski, Peter Bailis.

A high-level overview blogpost on this paper.

Many applications were found to be vulnerable to this, eg. WooCommerce, Opencart.

There are two types of anomaly that ACIDRain attacks could trigger, dependent on the application involved:

1. Level-based isolation anomalies, which are races due to isolation settings at the database-level i.e. the database may not support serializability, or may not have been configured to do so (this is the case for most deployed databases in the wild).
2. Scoping isolation anomalies, which occur when an application programmer fails to correctly encapsulate logic using transactions. This enables concurrent requests to impact behavior that could not have arisen sequentially.

It sounds like both can be solved by enforcing Serializable isolation level for transactions. Is it correct?

Also, some database doesn't have real Serializable isolation level, for example Oracle. What can be done to protect them from this type of attack?

Answer 1

To use SERIALIZABLE to guarantee truly serial transactions, every transaction would have to acquire a global lock on all tables in the database. There's no way to know in advance what data your transaction will try to read or update, so a global lock is the only real guarantee.

Both Oracle and MySQL have a transaction isolation level that they term SERIALIZABLE, but they take an optimistic strategy. Though each does so in different ways, neither does a global lock as I described above.

MySQL implements SERIALIZABLE in a simple way: Every SELECT is implicitly SELECT...LOCK IN SHARE MODE (known as SELECT...FOR SHARE in 8.0). This means that if two sessions read the data and then try to update it as shown in the balance debit example in the paper, they'll cause a deadlock because both updates will be waiting for the other to release its shared read lock.

Oracle allows you to read and update data, and acquires locks optimistically (i.e. at the time you read or update). But if you try to update data that has been modified since your transaction began, you get this error:

ORA-08177: can't serialize access for this transaction

In both Oracle and MySQL, the best remedy for the ACIDRain vulnerability has nothing to do with isolation level. The remedy is to avoid the race condition by using explicit locking reads using the FOR UPDATE query option. That ensures exclusive access to the data starting at the time you read the data.

Another remedy would be to issue explicit table-locking commands, such as LOCK TABLES in MySQL or LOCK TABLE in Oracle.

References:

• https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html
• https://blogs.oracle.com/oraclemagazine/on-transaction-isolation-levels