Re: Black Hat: New database attack revealed

Chris Browne wrote:

>Lukas Kahwe Smith <smith(at)pooteeweet(dot)org> writes:
>
>
>>Chris Browne wrote:
>>
>>
>>
>>>Cacheing tends to make lots of operations run more quickly, ergo in
>>>"about the same time," for the small, simple queries.
>>>
>>>
>>Well but since the attack is based on inserting data, wouldnt this
>>likely cause cache invalidation in many cases?
>>
>>
>
>Perhaps to some degree, but it is not at all clear that it will be
>material. If they're adding new tuples to a predictable set of
>tables, in large quantity, this will tend to lead to a pattern of:
>
> - Allocating a new page (which will throw in a little bit of variance)
> - Adding several tuples to that page
>
>The index work will tend to draw a bunch of pages for the relevant
>tables into cache, which should tend to stabilize, unless they're
>actually throwing so much data at the system that they're really
>making the DB larger, at which point I'd expect the "real" data to
>start to disappear, washed out by their data.
>
>
Dwelling on this issue *way* more than I think it deserves:

Any noise in the signal, including caching, vacuuming, other queries,
etc., can be averaged out, given a sufficient number of samples. Even
if the signal is very small and the noise is very large. The more noise
there is (relative to the signal), the more samples you need to average
the noise out, but the existence of noise doesn't disprove the
theoretical capability of the attack.

However, it does introduce a pragmatic concern- basically that the
necessity for large numbers of samples (queries) in order to overcome
the noise problem is itself a very noticeable effect. If you need to
spend days, weeks, or even months hammering a database server to get
enough samples in order to average out the noise, even the most obtuse
admin is likely to notice (if for no other than reason than all of the
other users of the database complaining about the slow performance).

Brian