develooper Front page | perl.perl5.porters | Postings from November 2003

Re: Hypothetical attack on 5.8.1 randomized hashes.

Thread Previous | Thread Next
From:
Scott A Crosby
Date:
November 1, 2003 16:21
Subject:
Re: Hypothetical attack on 5.8.1 randomized hashes.
Message ID:
oydk76j4o57.fsf@bert.cs.rice.edu
On Fri, 31 Oct 2003 18:34:07 +0000, Alan Burlison <Alan.Burlison@sun.com> writes:

> Scott A Crosby wrote:
> 

> > Although true, this is inapplicable. Generally the timer interrupt is
> > only used to context switch out of a task that doesn't otherwise
> > block. Normally on an idle machine if a task is blocked and anything
> > comes in to unblock it. (Either from a timeout in sleep() or select()
> > or incoming data from the network) it is unblocked and run
> > immediately.
> 
> Except on a heavily loaded machine - like one that is under attack,
> say... 

The goal of this attack is to reverse-engineer the hash seed. In order
to do that, the attacker wants the victims load to be minimized to
avoid noise. Once the hash seed is discovered, the attacker custom
constructs an set of hash input designed to put the victim under high
load. (Also, news. I have figured out how to precompute most of the
work required to determine the hash seed. It should now take on the
order of an hour or less.)

> And the latency involved with a context switch is not
> inconsiderable, and not predictable, and machines with more than 1
> CPU will have a different profile anyway...

My test earlier that showed a 17ns latency range required one context
switch per packet, or about 2500 per second on the server and client
end. This program queries a carefully calibrated server process but it
does show that network latency can be calibrated to microsecond levels
in some cases. Future work is how much system jitter something like
Apache introduces. The recent OpenSSL attack --- where they used
remote timing analysis to tease out an SSL private key out of a
webserver[1] --- puts an upper bound on that jitter.

> I'd be astonished if this attack was realisable.  There is too much
> else going on to make this predictable - for example page faults.

We know that at least two remote timing attacks are possible.[1] We do
not know the scope --- what else is possible --- and the more general
question of how accurately a remote attacker can obtain timing
information. You may be right and we can't attack perl's hash table
remotely, but until someone actually analyzes it, we won't know.

Scott


[1] http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

    Timing attacks are usually used to attack weak computing devices
    such as smartcards. We show that timing attacks apply to general
    software systems. Specifically, we devise a timing attack against
    OpenSSL. Our experiments show that we can extract private keys
    from an OpenSSL-based web server running on a machine in the local
    network. Our results demonstrate that timing attacks against
    network servers are practical and therefore all security systems
    should defend against them.


Interesting, I just found a second attack on OpenSSL when looking up
the first reference:

http://linux.oreillynet.com/pub/a/linux/2003/02/24/insecurities.html

    A timing-based attack against OpenSSL has been reported. This
    attack can be used under some conditions to retrieve a text block,
    such as a user's password. This attack is described in a paper
    written by Brice Canvel, Alain Hiltgen, Serge Vaudenay, and Martin
    Vuagnoux that is to be presented at CRYPTO 2003.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About