bugtraq - Re: Syscall implementation could lead to whether or not a file exists

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 6 Apr 2003 22:31:47 +0200
From: Pavel Machek <pavel@...e.cz>
To: Andrew Griffiths <andrewg@...net.au>
Cc: full-disclosure@...ts.netsys.com, bugtraq@...urityfocus.com
Subject: Re: Syscall implementation could lead to whether or not a file exists


Hi!

> 	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.

Umm, this is nasty. Random delay in "return -EPERM" path would not
help; making sure every syscall returning EPERM last at least 20usec
would but implementing that would be hard.
								Pavel
-- 
When do you have heart between your knees?
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html