[<prev] [next>] [day] [month] [year] [list]
Message-ID: <3E8B37D3.50906@d2.net.au>
From: andrewg at d2.net.au (Andrew Griffiths)
Subject: Syscall implementation could lead to whether or not a file exists
Product: Linux and various other kernels
Tested:
- RedHat kernel 2.4.18-26.7.x (second latest ;))
- RedHat kernel 2.4.18-27.7.x
- Debian 3.0 box
- FreeBSD 4.4
Description:
Due to the implementation of various system calls, it becomes
possible to test whether or not a file exists in a directory
that is unreadable.
Synopsis:
Filenames can be disclosed, which may be useful for other
attacks.
Problem:
By timing how long it takes for the system call to return, you
can pretty tell whether or not the file exists, because the
failure time is in my testing, three times shorter than if the
file exists.
To illistrate, here is an example of the attached program
running with the open() call. I would think other syscalls such
as stat(), mkdir(), chdir(), etc would disclose whether or not a file
exists.
[+] creating unreachable
[+] creating unreachable/iexist
[+] chmod 0'ing unreachable
[+] d--------- 2 andrewg andrewg 4096 Mar 20 20:37 unreachable/
[+] Timing open() on unreachable/iexist
[+] Successful: 12 usecs, got Permission denied
[+] Timing open() on unreachable/non-existant
[+] Failure: 3 usecs, got Permission denied
[+] Using 3 as our cutoff.
[+] testing /root/.bashrc and /root/non-existant
[+] /root/.bashrc exists (4 usecs), got Permission denied
[+] /root/non-existant doesn't exist (2 usecs), got Permission denied
After a while of experimentation, I found that the following
formuala seems to be relatively decent at avoiding false
positivites, on my RH box.
cutoff = ((success_time + failure_time) / 3) - 2
This is somewhat dependant on the load on the box, and where the file
is located, though it appears.
On some OS's (notably freebsd in my testing) it will store the
results of into its cache (different to linux, in the sense that it
throws off the algo above.). Thus, if you just create a file and time
open()ing that, then compare it with a file that has
been recently opened, you don't get a fair comparsision.
Fix:
No known fix exists. Not exactly sure whether a fix is
appropiate, as the kernel is meant to be as fast as possible.
Exploit:
is attached.
Information is this email may be redistributed as long as the below
signature stays attached.
Thanks,
Andrew Griffiths
--
Attention: Public floggings will continue until morale improves.
MidWay_/#melb-wireless licks txrxafk while his defenses are down.
<MidWay_> Oh boy. That could have been taken out of context.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: filetest.c
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030403/c6085d0d/filetest.c
Powered by blists - more mailing lists