Re: any NX memory areas?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
>>>
>>
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux