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
| ||
|
Date: Sun, 16 Jul 2006 03:54:27 +0200 From: Pavel Machek <pavel@...e.cz> To: andrea@...share.com Cc: Valdis.Kletnieks@...edu, Alan Cox <alan@...rguk.ukuu.org.uk>, ajwade@...001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com, Lee Revell <rlrevell@...-job.com>, "Randy.Dunlap" <rdunlap@...otime.net>, Andrew Morton <akpm@...l.org>, bunk@...sta.de, linux-kernel@...r.kernel.org, mingo@...e.hu Subject: Re: [2.6 patch] let CONFIG_SECCOMP default to n > On Fri, Jul 14, 2006 at 10:55:28PM -0400, Valdis.Kletnieks@...edu wrote: > > In fact, the best you can do here is to reduce the effective bandwidth > > the signal can have, as Shannon showed quite clearly. > > Yes. > > > And even 20 years ago, the guys who did the original DoD Orange Book > > requirements understood this - they didn't make a requirement that covert > > channels (both timing and other) be totally closed down, they only made > > a requirement that for higher security configurations the bandwidth of > > the channel be reduced below a specified level... > > Why I think it's trivial to guarantee the closure of the seccomp side > channel timing attack even on a very fast internet by simply > introducing the random delay, is that below a certain sampling > frequency you won't be able to extract data from the latencies of the > cache. The max length of the random noise has to be >= of what it > takes to refill the whole cache. Then you won't know if it was a > cache You won't know for sure... but. Let t be time takes to reload the cache. Let your random noise be in <0, t> interval. According to you, that would be okay. IT IS NOT. If the original delay was long, and your generator returned t, attacker sees 2*t. He can be _sure_ delay was long now. If the delay was short, and your generator returns 0, attacker sees 0, and _knows_ delay was short. (Chance that generator produces 0 or t is small, but non zero). Even if you do random noise in <0, 2*t) interval, I'll be able to gather some statistics. Pavel Thanks, Sharp! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists