Re: Black Hat: New database attack revealed - Mailing list pgsql-advocacy

dpage@postgresql.org (Dave Page) writes:
> Peter Eisentraut wrote:
>> Am Donnerstag, 2. August 2007 13:31 schrieb Robert Bernier:
>>> New timing attack doesn't need application bugs to work
>>>
>>> http://www.computerworlduk.com/management/security/cybercrime/news/index.cf
>>> m?RSS&newsid=4344
>>
>> This is complete BS, as evidenced by this statement:
>>
>> """
>> their attack involves performing record insertion operations, typically
>> available to all database users - including anonymous users of front-end web
>> applications - and analysing the time it takes to perform different kinds of
>> insertions.
>> """
>>
>> In principle, attacks of this kind would be possible, but it's not quite as
>> simple as they make it appear.
>
> That was roughly my thought as well.
>
> In our case, would it even be possible given WAL?

That's only one of many things that would be likely to affect this.

- If there are multiple users doing work, that'll throw in load, in
  general, to make it harder to distinguish timing information.

- Inserting has several effects, including:

  - Throwing the new tuple onto a page.  Several possibilities
    ensue...

    - Maybe it goes at the end of the DB file, in which there is a
      risk of lock contention on that page that will throw timing
      off.

    - Maybe the location of the tuple was determined by the FSM, in
      which case, it takes some time to look up that location, and
      there *shouldn't* be lock contention on the page.

    - If PCTFILLED is less than 100% (e.g. - we're trying to keep
      space free), there's some extra scattering effect.

    - I'll bet the upcoming "trying to keep tables CLUSTERed"
      functionality affects behaviour...

  - Then come index updates.

    - If there are few indices, then effects should be low.
    - If there are multiple concurrent updaters, there may be
      timing effects from page locking.

Lots of "maybes" here, but certainly lots of things *likely* to happen
that will throw off attempts to time things.  Configuration would also
have big effects on timings; more cache would generally make some
operations take less time, thereby drawing timings together, and
cutting down on the variations that the "attacker" is trying to
measure.

Unlike the RSA attacks, it's not evident that an attacker would
deterministically know terribly much about the contents of the
database based on having this timing information.

This might be significant if:
- you had just one or two streams of updates coming in, and
- you were running a database without cache.

Maybe there are Competing Products We Oughtn't Name that have somewhat
more deterministic timing behaviours, but this seems like a terribly
dubious attack to me...
--
output = reverse("moc.enworbbc" "@" "enworbbc")
http://cbbrowne.com/info/multiplexor.html
"The entire structure of the antitrust statutes in this country is a
jumble of economic irrationality and ignorance. It is the product: (a)
of a gross misinterpretation of history; and (b) of rather naive, and
certainly unrealistic, economic theories."
-- Alan Greenspan