jm + isolation   2

[no title]
'For decades, the transaction concept has played a central role in
database research and development. Despite this prominence, transactional
databases today often surface much weaker models than the
classic serializable isolation guarantee—and, by default, far weaker
models than alternative,“strong but not serializable” models such as
Snapshot Isolation. Moreover, the transaction concept requires the
programmer’s involvement: should an application programmer fail
to correctly use transactions by appropriately encapsulating functionality,
even serializable transactions will expose programmers
to errors. While many errors arising from these practices may be
masked by low concurrency during normal operation, they are susceptible
to occur during periods of abnormally high concurrency. By
triggering these errors via concurrent access in a deliberate attack, a
determined adversary could systematically exploit them for gain.
In this work, we defined the problem of ACIDRain attacks and
introduced 2AD, a lightweight dynamic analysis tool that uses traces
of normal database activity to detect possible anomalous behavior
in applications. To enable 2AD, we extended Adya’s theory of weak
isolation to allow efficient reasoning over the space of all possible
concurrent executions of a set of transactions based on a concrete
history, via a new concept called an abstract history, which also
applies to API calls. We then applied 2AD analysis to twelve popular
self-hosted eCommerce applications, finding 22 vulnerabilities
spread across all but one application we tested, affecting over 50%
of eCommerce sites on the Internet today.

We believe that the magnitude and the prevalence of these vulnerabilities
to ACIDRain attacks merits a broader reconsideration of
the success of the transaction concept as employed by programmers
today, in addition to further pursuit of research in this direction.
Based on our early experiences both performing ACIDRain attacks
on self-hosted applications as well as engaging with developers, we
believe there is considerable work to be done in raising awareness
of these attacks—for example, via improved analyses and additional
2AD refinement rules (including analysis of source code to
better highlight sources of error)—and in automated methods for defending
against these attacks—for example, by synthesizing repairs
such as automated isolation level tuning and selective application
of SELECT FOR UPDATE mechanisms. Our results here—as well as
existing instances of ACIDRain attacks in the wild—suggest there
is considerable value at stake.'
databases  transactions  vulnerability  security  acidrain  peter-bailis  storage  isolation  acid 
5 weeks ago by jm
Understanding weak isolation is a serious problem
Peter Bailis complaining about the horrors of modern transactional databases and their unserializability, which noone seems to be paying attention to:

'As you’re probably aware, there’s an ongoing and often lively debate between transactional adherents and more recent “NoSQL” upstarts about related issues of usability, data corruption, and performance. But, in contrast, many of these transactional inherents and the research community as a whole have effectively ignored weak isolation — even in a single server setting and despite the fact that literally millions of businesses today depend on weak isolation and that many of these isolation levels have been around for almost three decades.'

'Despite the ubiquity of weak isolation, I haven’t found a database architect, researcher, or user who’s been able to offer an explanation of when, and, probably more importantly, why isolation models such as Read Committed are sufficient for correct execution. It’s reasonably well known that these weak isolation models represent “ACID in practice,” but I don’t think we have any real understanding of how so many applications are seemingly (!?) okay running under them. (If you haven’t seen these models before, they’re a little weird. For example, Read Committed isolation generally prevents users from reading uncommitted or non-final writes but allows a number of bad things to happen, like lost updates during concurrent read-modify-write operations. Why is this apparently okay for many applications?)'
acid  consistency  databases  peter-bailis  transactional  corruption  serializability  isolation  reliability 
september 2014 by jm

Copy this bookmark:



description:


tags: