| |||||||||||||
Move along, nothing to see hereMove along, nothing to see herePosted Feb 3, 2005 13:17 UTC (Thu) by brugolsky (subscriber, #28)Parent article: Address space randomization in 2.6 This piece would have been better titled Red Hat Conspiracy of the Week. In this week's drama, Red Hat attempts to crush all value-added secure distributions by distributing snake oil to the masses. If a group uses an intrusive kernel patch, and a well-known kernel hacker seeks to have code merged that will shrink at least part of that patch down to the tweaking of a single constant, what again is the problem? The whole thread is absurd -- anyone who cares so much about address space randomization ought to run on a 64-bit platform!
(Log in to post comments)
Move along, nothing to see here Posted Feb 12, 2005 15:18 UTC (Sat) by spender (subscriber, #23067) [Link] Being such an expert on the subject, can you please tell me the number of addressable bytes of memory on the following 64 bit architectures:ALPHA SPARC64 X86-64
Now, since you're also such an expert on the topic, please tell me how many bits of randomization you can provide for the brk-managed heap, the mmap base, and stack for the above architectures.
Please also inform me of how many applications on the above architectures are built 64-bit and thus can make use of such randomization.
Looking forward to your reply.
The "it stops automated remote attacks" position is pretty funny. What about automated bruteforcing remote attacks? Surely that's the next step that will show this feature by itself to be what it is: obscurity. It has more real benefit for other architectures that support the NX bit properly, but if your goal is to provide protection against "automated remote attacks" for the general user, shouldn't your solution be targeted towards the architecture the general user uses?
|
|||||||||||||