Hendrik Weimer wrote:
Al Stone <[EMAIL PROTECTED]> writes:
I could be completely wrong. Would it be possible for you to
send me a demonstration of this scenario?
Suppose a server performs password checking by
strncmp(user_supplied_password, password_stored_in_database, size).
Now strncmp does its comparison by subsequently comparing parts of the
two strings. Since OProfile allows profiling other users' processes a
local attacker can see after how many parts the two strings differ. He
knows which parts of his entered string are correct and therefore can
greatly reduce the key space.
Even though this example is a bit far-fetched, I think you'll get the
idea. Real world attacks would probably be directed at cryptographic
keys, e.g. in the spirit of [1].
Probably the best solution would be to restrict reading
/var/lib/oprofile/samples/current/{$USER}/ to $USER.
Hendrik
[1] http://www.cs.cmu.edu/~dbrumley/pubs/openssltiming.pdf
OProfile does not provide the direct timing latency of how long it took
to get from point A to point B in the code or the exact path in the
code. OProfile provides sampling information in
/var/lib/oprofile/samples. OProfile could provide information about
whether a particular instruction is execute. The relative frequency of
the samples could provide some information about how things are working.
For this type of attack to be successful wouldn't there have to be a lot
of tries to build up meaningful statistics that are not drowned out by
other things running on the system (interupts and other processes)? The
cracker could force dumps and keep track of the changes in the
/var/lib/oprofile/samples/current of interest.
-Will
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
