* Andi Kleen <ak@xxxxxxx> wrote: > On Thursday 18 May 2006 18:02, Ingo Molnar wrote: > > > > * Andi Kleen <ak@xxxxxxx> wrote: > > > > > The security argument seems quite bogus to me for this because you'll > > > never find enough bits to be reasonably secure in the limited 32bit > > > space. > > > > i'm surprised to still see this old (and dangerously misleading) > > argument. Even the current limited amount of randomization on i386 is > > pretty powerful against certain classes of worms and automated attacks. > > It just increases their work a bit after they caught up. > > For a worm 1 or 256 tries is not that big a difference. sorry but this is so incorrect that it's not even wrong! Recommended reading would be the Sapphire (Slammer) worm's spreading model: http://www.caida.org/outreach/papers/2003/sapphire/sapphire.html some quotes: The Sapphire Worm was the fastest computer worm in history. As it began spreading throughout the Internet, it doubled in size every 8.5 seconds. It infected more than 90 percent of vulnerable hosts within 10 minutes. [...] and in particular: Sapphire contains a simple, fast scanner in a small worm with a total size of only 376 bytes. With the requisite headers, the payload becomes a single 404-byte UDP packet. This can be contrasted with the 4kb size of Code Red, or the 60kb size of Nimda. Previous scanning worms, such as Code Red, spread via many threads, each invoking connect() to probe random addresses. Thus each thread's scanning rate was limited by network latency, the time required to transmit a TCP-SYN packet and wait for a response or timeout. [...] even forcing 256 tries (which is only 256 in upstream's crippled ASLR, which was crippled partly due to misguided efforts of yours ...) _dramatically_ changes the spreading model of a worm. Frankly, i find it frustrating having to repeat this simple point so many times during so many years. This is really not rocket science. i'd suggest for you to somehow start eliminating your apparent phobia against exec-shield and ASLR in particular. Linux really needs better ASLR - but it cannot be done without active and willing participation of architecture maintainers. If i sound bitter than that's not really directed towards you personally, it's more due to the unjust flak that exec-shield got during the years. In any case, regarding this topic i wont be tactful anymore. Not doing proper ASLR _now_ is simply negligience towards our users. Even doing it yesterday would be too late. > > But you dont have to believe me - check the exploit templates that > > make use of the VDSO page on x86_64. ] > > You mean the 64bit vsyscalls? > > Yes, that was a bit poor early design. At some point it has to go over > to ELF based, especially when we run out of them (which should happen > soon) > > But I believe i have plugged this hole for most systems. The syscall > instructions are noped out for kernels which don't need it for the > pmtimer (which is at least all nearly all Intel systems and many AMD > systems). And there shouldn't be any other SYSCALL byte combinations > in the vsyscall page. I don't know of any other ways to abuse that > page without a syscall instruction. there is nothing bad about vsyscalls, and i expect them to be utilized more in the future. (just think rdtscp) So if you think the problem has been 'solved' by the apparent temporary non-use of vsyscalls on some systems, i think you are dangerously wrong again! If you think the situation is OK then hell just do 'cat /proc/self/maps' a couple of times on a SuSE system. Do it on i386. Do it on x86_64. Do the same on Fedora. Then think about what you see! > The 32bit VDSO is not randomized, but that's the same as native i386. in exec-shield it's randomized of course. It's not hard once it's a vma. Ingo
