| 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
| ||
|
From: andrewg at d2.net.au (andrewg@...net.au) 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. Under linux, I would think you could do this in the return from the calling of sys_call_table easily, in the interrupt handler ;) However, extending the time the interrupt takes, imo, is bad. > Pavel > -- > When do you have heart between your knees? > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html Thanks, Andrew Griffiths
Powered by blists - more mailing lists