lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ