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]
Message-ID: <20030406203147.GB421@elf.ucw.cz>
From: pavel at suse.cz (Pavel Machek)
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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ