Sorry, and another article too: Bypassing PaX ASLR protection On Wed, Mar 11, 2009 at 11:55 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: > Bypassing PaX - check out this Phrack article: > > The advanced return-into-lib(c) exploits > > On Wed, Mar 11, 2009 at 11:51 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >> the best I can find is this: >> >> http://wapedia.mobi/en/Executable_space_protection >> >> which indicated that ExecShield was rejected because of some >> "intrusive changes". >> >> And reading this: >> >> http://wapedia.mobi/en/Exec_Shield >> >> ExecShield is only an emulation, not really requiring true hardware >> support, and thus entailing some performance tradeoffs. >> >> whereas PaX truely used NX bit....readup the patches. But then again..... >> >> 1. There are ways (in another Phrack article) to bypass the PaX protection. >> 2. The PaX patches may break some applications etc. And most >> important....PAE is slooooooooooooooooooooooooow. >> >> http://lkml.indiana.edu/hypermail/linux/kernel/0612.1/0632.html >> >> On Wed, Mar 11, 2009 at 11:03 AM, Pei Lin <telent997@xxxxxxxxx> wrote: >>> i think if date area can execute code ,it is really very dangerous for >>> cracker who can easily write >>> shellcode like : >>> >>> char shellcode[]={}; >>> void (*fp)() = shellcode; >>> fp(); >>> >>> these some virus lovers give examples: >>> http://www.governmentsecurity.org/forum/lofiversion/index.php/t31130.html >>> >>> I search on the internet and Ingo give some ideas >>> about 'Exec Shield' - new Linux security feature. >>> http://www.linux.com/feature/29186?theme=print >>> >>> i don't know the kernel has these feature now.who know that plz tell >>> us the details. >>> >>> thx >>> >>> Lin >>> >>> 2009/3/11 NAHieu <nahieu@xxxxxxxxx>: >>>> On Wed, Mar 11, 2009 at 10:46 AM, NAHieu <nahieu@xxxxxxxxx> wrote: >>>>> On Tue, Mar 10, 2009 at 4:13 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >>>>>> Sorry, my mistake, PAE is required yes, and then 32bit Linux Kernel >>>>>> will have NX enabled: >>>>>> >>>>>> PAE can be enabled with CONFIG_X86_PAE (and CONFIG_HIGHMEM64G - >>>>>> possibly needed, which is what the kernel config file for Fedora Core >>>>>> 11 has): >>>>>> >>>>>> In arch/x86/mm/init_32.c: >>>>>> >>>>>> #ifdef CONFIG_X86_PAE >>>>>> set_nx(); >>>>>> if (nx_enabled) >>>>>> printk(KERN_INFO "NX (Execute Disable) protection: active\n"); >>>>>> #endif >>>>> >>>>> That is indeed what happens in the kernel code. However, now I really >>>>> have some doubts now after reading the Intel manual 3A. >>>>> >>>>> According to 3.8.5, PAE mode in x86 reserves all the bits from 36-63 >>>>> to 0. Knowing that bit 63 is for NX, this means NX bit is never on, so >>>>> no page can be set with NX bit. As a result, all the pages in x86 >>>>> cannot prohibit execution. >>>>> >>>>> Meanwhile, 3.10.3 clearly mentions NX bit can be turned on in x86-64 >>>>> (IA32e in Intel term). >>>>> >>>>> So this means NX is really only possible in 64bit OS??? But then why >>>>> Linux 32 turns on NX? >>>>> >>>>> Could anybody confirm this confusion? >>>> >>>> Hmm now I see the reason: 4.13.3 says that the reserved bits are >>>> checked when PAE is on. >>>> >>>> My question still stands: why some (every?) data areas dont prohibit >>>> execution in x86 Linux? >>>> >>>> Thanks, >>>> H >>>> >>>> >>>> >>>>>> On Tue, Mar 10, 2009 at 12:23 PM, NAHieu <nahieu@xxxxxxxxx> wrote: >>>>>>> On Mon, Mar 9, 2009 at 11:50 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >>>>>>>> as far as I can remember, in x86 architecture, hardware-wise, it is >>>>>>>> NOT possible to enable NX. U may do anything via software, but it >>>>>>>> will not be enabled. NX feature is only for 64bit OS. >>>>>>>> >>>>>>> >>>>>>> No, NX is available for 32bit Linux, as long as PAE is enable. >>>>>>> >>>>>>> I am still stuck here (on 32bit Linux). It seems nobody can shed some >>>>>>> lights in this problem? >>>>>>> >>>>>>> Thanks, >>>>>>> H >>>>>>> >>>>>>> >>>>>>>> On Mon, Mar 9, 2009 at 4:27 AM, NAHieu <nahieu@xxxxxxxxx> wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I inspect my Linux memory, and it seems that there is no area that >>>>>>>>> prohibite execution like I expected (using NX bit in modern CPU). That >>>>>>>>> really surprises me. >>>>>>>>> >>>>>>>>> I looked at some potential data areas exported in System.map file, like: >>>>>>>>> >>>>>>>>> - mark_rodata_ro >>>>>>>>> - sysctl_data >>>>>>>>> - new_cpu_data >>>>>>>>> - boot_cpu_data >>>>>>>>> >>>>>>>>> And all of these areas allow to execute code (because NX=0 there). Is >>>>>>>>> that really desirable? >>>>>>>>> >>>>>>>>> Anybody know for sure which area (easier to check if exported in >>>>>>>>> System.map) doesnt allow execute? >>>>>>>>> >>>>>>>>> I can confirm that NX is active in my machine (reported in dmesg) >>>>>>>>> >>>> >>> >> >> >> >> -- >> Regards, >> Peter Teoh >> > > > > -- > Regards, > Peter Teoh > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
