A Portable Implementation Framework for IntrusionResilient Database Management Systems

1
A Portable Implementation Framework for
Intrusion-Resilient Database Management Systems

• Alexey Smirnov and Tzi-cker Chiueh
• Department of Computer Science
• SUNY at Stony Brook
• DSN 2004

2
Outline

• Motivation
• System Architecture
• Transaction Dependency Tracking
• Database Repair Process
• Performance Evaluation
• Summary

3
Motivation

• Suppose you are a DBA and you have just noticed
  that your database has been compromised 24 hours
  ago. How would you repair the database?
• Currently, the only way to do this is to restore
  a database backup and manually recommit benign
  transactions.
• Difficulties (1) how to tell benign transactions
  from malicious (2) the amount of data can be
  huge and the repair process is very error-prone.

4
Motivation

• Ideally, an intrusion-resilient DBMS should be
  able to
• Track inter-transaction dependencies
• Perform a selective transaction rollback.
• We propose implementation framework called RDB
  that can render an off-the-self DBMS intrusion
  resilient without modifying its internals. RDB
  has two components tracking subsystem which runs
  at run-time and recovery subsystem which runs
  offline.

5
Definition of Transaction Dependency

• A read set of an SQL statement S is the set of
  rows fetched by this statement.
• We will say that statement S2 depends on
  statement S1 if at least one row from the read
  set of S2 was modified by S1.
• We will say that transaction T2 depends on
  transaction T1 if at least one statement of T2
  depends on a statement from T1.

6
Limitations of Transaction Dependency Model

• This definition is prone to both false positives
  and false negatives.
• Example of a false positive dependency

7
Limitations of Transaction Dependency Model

• This definition is prone to both false positives
  and false negatives.
• Example of a false positive dependency

T1 SET A25 WHERE A1lt250
8
Limitations of Transaction Dependency Model

• This definition is prone to both false positives
  and false negatives.
• Example of a false positive dependency

T1 SET A25 WHERE A1lt250
T2 SELECT A3 WHERE A3gt3
9
Limitation of Transaction Dependency Model

• Another limitation is that in general, it is
  impossible to determine all transaction
  dependencies by looking at the traffic between a
  client and the DB server only because part of the
  logic may be inside the application itself.

10
How to Track Transaction Dependencies?

• Such a tracking mechanism should be able to
  intercept both read and write actions performed
  in the database. Possible approaches are

11
How to Track Transaction Dependencies?

• Such a tracking mechanism should be able to
  intercept both read and write actions performed
  in the database. Possible approaches are

Database log analysis read actions are not
logged
12
How to Track Transaction Dependencies?

• Such a tracking mechanism should be able to
  intercept both read and write actions performed
  in the database. Possible approaches are

Database log analysis read actions are not
logged
Database triggers will miss out SELECT
statements
13
How to Track Transaction Dependencies?

• Such a tracking mechanism should be able to
  intercept both read and write actions performed
  in the database. Possible approaches are

Database log analysis read actions are not
logged
Database triggers will miss out SELECT
statements
Tracking proxy will intercept SQL statements
coming from the client to the server
14
Transaction Dependency Tracking

• RDB inserts a proxy JDBC driver between the DB
  server and a client that transparently intercepts
  all queries and results. The proxy can be either
  on the client side

15
Transaction Dependency Tracking

• RDB inserts a proxy JDBC driver between the DB
  server and a client that transparently intercepts
  all queries and results. The proxy can be either
  on the client side

16
Transaction Dependency Tracking

• RDB inserts a proxy JDBC driver between the DB
  server and a client that transparently intercepts
  all queries and results. The proxy can be either
  on the client side or on the server side.

17
Transaction Dependency Tracking

• The following changes are made to the database at
  the time of its creation
• Table trans_dep(tr_idINTEGER, dep_tr_idsVARCHAR)
  stores IDs of transactions that depend on
  transation tr_id
• Table annot(tr_idINTEGER, descrVARCHAR)
  stores annotation for transaction tr_id
• A new field tr_id is added to each table. It
  contains the ID of last transaction that modified
  each row.
• The proxy uses its own transaction IDs because
  there is no standard way to access internal
  transaction ID.

18
Transaction Dependency Tracking

• The JDBC proxy needs to update field tr_id when
  the data is modified and to select it when the
  data is fetched. The proxy rewrites SQL
  statements coming from the client.

SELECT a FROM t WHERE c
SELECT a, t.tr_id FROM t WHERE c
19
Transaction Dependency Tracking

• The JDBC proxy needs to update field tr_id when
  the data is modified and to select it when the
  data is fetched. The proxy rewrites SQL
  statements coming from the client.

UPDATE t SET av WHERE c
UPDATE t SET av, tr_idcurTrID WHERE c
20
Transaction Dependency Tracking

• The JDBC proxy needs to update field tr_id when
  the data is modified and to select it when the
  data is fetched. The proxy rewrites SQL
  statements coming from the client.

INSERT INTO t(a) VALUES(v)
INSERT INTO t(a, tr_id) VALUES(v, curTrID)
21
Transaction Dependency Tracking

• The JDBC proxy needs to update field tr_id when
  the data is modified and to select it when the
  data is fetched. The proxy rewrites SQL
  statements coming from the client.

COMMIT
INSERT INTO trans_dep(curTrID,) COMMIT
22
Summary of the Tracking Subsystem

• Transaction dependency tracking is implemented as
  a JDBC proxy driver and is therefore highly
  portable across different DBMSs.
• The proxy uses a lightweight approach aimed at
  tracking all read actions in a database.

23
Database Repair Process

• The database is repaired by committing
  compensating transactions.
• When using RDB, the repair process consists of
• Database log analysis (to reconstruct complete
  dependency information and generate compensating
  transactions)
• Dependency graph visualization
• Repairing the database by committing compensating
  transactions

24
Database Log Analysis

• At repair time, RDB analyses the database
  transaction log to build a complete dependency
  graph and to generate compensating transactions.
  Different DBMSs provide different facilities for
  log analysis. We have studied three DB servers
• PostgreSQL 7.2.2
• Oracle 9.2.0
• Sybase ASE 12.5

25
Database Log Analysis

• Oracle LogMiner translates binary log into a
  database view that can be queried. It contains
  the transaction ID, the original SQL statement
  and a compensating SQL statement.
• PostgreSQL no end-user programs or APIs for log
  analysis. We have implemented a plugin that
  provides a LogMiner-kind functionality
• Sybase can provide a dump of its binary
  transaction log. The format of this dump is
  partially described in Sybase manuals. We have
  developed a tool that parses this dump and
  generates compensating statements.

26
Dependency Graph Visualization

• We used GraphViz (ATT)
• The application allows the user to select an
  initial set of malicious transactions and
  computes its transitive closure. Then the result
  can be refined by the user to build the final set
  of transactions to be undone.
• We are working on a more powerful tool that can
  discard certain types of dependencies.

27
Performance Evaluation

• We used TPC-C benchmark to evaluate the run-time
  overhead of JDBC proxy.
• Test database size 4GB.
• We varied the following parameters
• Transaction mix (read intensive and read/write
  intensive)
• Connection type (local or over a network)
• Total footprint size (effect of database cache)

28
Performance Evaluation

• Overhead is between 6 and 13.

29
Performance Evaluation

• Our interpretation of these results the overhead
  comes mostly from additional writes to the
  database and transaction log.
• Why overhead for read-intensive transactions is
  less than that for read/write intensive when
  there are few dependencies, the number of
  additional writes is also small.
• Why overhead increases when the footprint
  decreases because there are fewer disk accesses
  performed on behalf of the client.

30
Summary

• We developed RDB, a portable framework that can
  render an off-the-shelf DBMS intrusion resilient
  without having access to its internals.
• The prototype has some limitations
• The tracking mechanism is row-based rather than
  column-based. This can lead to false
  dependencies.
• No support for stored procedures.
• Many DBMS vendors provide custom extensions to
  SQL. Currently, only part of SQL-92 is supported.