Database ACID characteristic

Database operation provides ACID characteristics.

Atomicity: All operations either occur or fail and are treated as single instructions.
Consistency: Any rules set (cascades, indexes, triggers) are correctly executed.
Isolation: Concurrent behavior shall be the same as sequential behavior.
Durability: Changes are persisted and shall not be lost, even with a DMBS crash.

Caveat:

In the banking scenario, each access (GetBalance, SetNewBalanceToDB) follows ACID, but the database has no knowledge (or control) over the additional logic.

Databases provide notions additional mechanisms to enforce ACID with macro operations.

CWE-362 – Example - Banking

Locks

LockDB();
$transfer_amount = GetTransferAmount();
$balance = GetBalance();

if ($transfer_amount < 0) {
    UnLockDB();
    FatalError("Bad Transfer Amount");
}

$nb = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {
    UnLockDB();
    FatalError("Insufficient Funds");
}

SetNewBalanceToDB($nb);
UnLockDB();
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

DB is locked.
No other operations take place.

Transactions

BeginTransaction();
$transfer_amount = GetTransferAmount();
$balance = GetBalance();

if ($transfer_amount < 0) {
    EndTransaction();
    FatalError("Bad Transfer Amount");
}

$nb = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {
    EndTransaction();
    FatalError("Insufficient Funds");
}

SetNewBalanceToDB($nb);
CommitTransaction();
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

DB Operations are queued.
Queue is discarded or committed atomically

Versioning

GetVersion();
$transfer_amount = GetTransferAmount();
$balance = GetBalance();

if ($transfer_amount < 0) {
    FatalError("Bad Transfer Amount");
}

$nb = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {
    FatalError("Insufficient Funds");
}

SetNewBalanceToDB($nb);
Commit();
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

At Commit(); DB version is acquired. Commit may FAIL if another change took place.

Improper Synchronization

// Global
shared_object_t data;

void update_data(char* cookie, pthread_mutex_t * mutex) {
    pthread_mutex_lock(mutex);
    // Manipulate global data object
    pthread_mutex_unlock(mutex);
}

Direct solution:

Protect changes with a mutex.

Developer assumes lock/unlock always work.

CWE-362 – Race Condition – Isolated Ops

X86_64: i++ with gcc

```
add    DWORD PTR [rbp-4], 1
```

X86_64: i++ with clang

```
mov    edi, dword ptr [rbp - 8]
```
```
add    edi, 1
```
```
mov    dword ptr [rbp - 8], edi
```

ARM: i++

```
ldr    r3, [fp, #-8]
```
```
add    r3, r3, #1
```
```
str    r3, [fp, #-8]
```

Developer thinks: i++ is a single operation.

In reality... it depends, and varies with the architecture.

Still (generic behavior).

Value of “i" must be available (previous logic).
Value must be fetched from RAM to Cache.
- Page must be addressed and then loaded.
- MMUs and other systems are used.
Value must be fetched from cache to Register.
Register as to be increased.
Result must be stored in Cache.
Result shall be committed to RAM.

CWE-362 - Improper Synchronization

The following function attempts to acquire a lock to perform operations on a shared resource.

The code does not check the value returned by pthread_mutex_lock() for errors.
If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

// Vulnerable
void f(pthread_mutex_t *mutex) {
    pthread_mutex_lock(mutex);
    /* access shared resource */
    pthread_mutex_unlock(mutex);
}

int f(pthread_mutex_t *mutex) {
    int result;
    result = pthread_mutex_lock(mutex);
    if (0 != result)
        return result;
    /* access shared resource */
    return pthread_mutex_unlock(mutex);
}

Last updated 1 year ago