Hello,
from somewhere in my INBOX, this claim was made:
>> (also note that userland processes can map 0x00000000 and the kernel
>> would jump to it ...)
In C code:
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <stdio.h>
int main(void) {
int fd = open("badcode.bin", O_RDONLY);
mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_FIXED, fd, 0);
}
The mmap() usually succeeds and maps something at address 0x00000000. Now
what if the kernel would try to execute this (of course badly programmed)
code in the context of this very process?
int (*callback)(int xyz) = NULL;
callback();
Would not be the badcode be executed with kernel privileges?
Jan Engelhardt
--
On Wed, 22 Feb 2006, Jan Engelhardt wrote:
> Hello,
>
>
>
> from somewhere in my INBOX, this claim was made:
>
>>> (also note that userland processes can map 0x00000000 and the kernel
>>> would jump to it ...)
>
> In C code:
>
> #include <sys/mman.h>
> #include <sys/ioctl.h>
> #include <fcntl.h>
> #include <stdio.h>
> int main(void) {
> int fd = open("badcode.bin", O_RDONLY);
int fd = open("/dev/mem", O_RDWR);
> mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_FIXED, fd, 0);
> }
>
> The mmap() usually succeeds and maps something at address 0x00000000. Now
> what if the kernel would try to execute this (of course badly programmed)
> code in the context of this very process?
>
> int (*callback)(int xyz) = NULL;
> callback();
>
> Would not be the badcode be executed with kernel privileges?
> Jan Engelhardt
> --
No. In your demo code, page 0 gets memory-mapped into user space.
This allows user-mode code to access the first page of memory
and even read/write offset 0, still in user mode, with the
root privs that allowed you access to that page in the
first place. Everything you do, is still in user-mode.
You just own some physical memory that the kernel didn't
care about anyway. FYI, the only "strange" thing is that
you can dereference a NULL pointer without error IFF the
"hint" passed to mmap() was a NULL. Mmap()s failure is
depicted by returning (void *) -1, not (void *) 0, so
a returned pointer value of 0 is perfectly okay and can
be used without a seg-fault. To prevent certain 'C'
runtime library functions from refusing to dereference
the pointer, it is best to give mmap() a "hint" of
some valid pointer value like 0x10000000. That will
prevent it from returning the (perfectly legal) NULL.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
>> int main(void) {
>> int fd = open("badcode.bin", O_RDONLY);
> int fd = open("/dev/mem", O_RDWR);
>
>> mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_FIXED, fd, 0);
>> }
>>
>No. In your demo code, page 0 gets memory-mapped into user space.
>This allows user-mode code to access the first page of memory
>and even read/write offset 0, still in user mode, with the
>root privs that allowed you access to that page in the
>first place.
Only root can map to 0x0?
>Everything you do, is still in user-mode.
>You just own some physical memory that the kernel didn't
>care about anyway.
So you can't accidentally call a place in userspace from kernel context?
(Including the case where set_fs(USER_DS) was used.)
Jan Engelhardt
--
On Thu, 23 Feb 2006, Jan Engelhardt wrote:
>>> int main(void) {
>>> int fd = open("badcode.bin", O_RDONLY);
>> int fd = open("/dev/mem", O_RDWR);
>>
>>> mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_FIXED, fd, 0);
>>> }
>>>
>> No. In your demo code, page 0 gets memory-mapped into user space.
>> This allows user-mode code to access the first page of memory
>> and even read/write offset 0, still in user mode, with the
>> root privs that allowed you access to that page in the
>> first place.
>
> Only root can map to 0x0?
>
>> Everything you do, is still in user-mode.
>> You just own some physical memory that the kernel didn't
>> care about anyway.
>
> So you can't accidentally call a place in userspace from kernel context?
> (Including the case where set_fs(USER_DS) was used.)
>
>
> Jan Engelhardt
> --
Nope. Try it, you'll like it! Play around with it, you can relocate
some code to play at offset 0, copy it there, and then call it.
It can't do anything bad, just because it's at a certain offset.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Jan Engelhardt wrote:
> The mmap() usually succeeds and maps something at address 0x00000000. Now
> what if the kernel would try to execute this (of course badly programmed)
> code in the context of this very process?
>
> int (*callback)(int xyz) = NULL;
> callback();
>
> Would not be the badcode be executed with kernel privileges?
I'm not sure, but I would suspect it might, yes, at least on some
platforms and configurations. However, this unlikely to be a serious
problem, since any kernel code that executed a callback method which
could be a NULL without checking for that would blow up the system in
the vast majority of cases where nothing was mapped at address 0.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On Wednesday 22 February 2006 15:10, you wrote:
> The mmap() usually succeeds and maps something at address 0x00000000. Now
> what if the kernel would try to execute this (of course badly programmed)
> code in the context of this very process?
>
> int (*callback)(int xyz) = NULL;
> callback();
>
> Would not be the badcode be executed with kernel privileges?
I am playing around with it.
I did the attached code. It is a usermode program, which tries to map NULL,
and a kernel module, which calls a NULL pointer.
The file badcode.bin contains an i386 ud2 instruction.
When loading the kernel module, while the usermode program is executing,
I get the usual NULL pointer dereference oops:
Calling NULL pointer...
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: kernel nvidia video battery fan button thermal processor ac nfs lockd sunrpc ath_pci ath_rate_sample wlan ath_hal usbhid tuner tvaudio msp3400 bttv video_buf firmware_class btcx_risc tveeprom ehci_hcd uhci_hcd usbcore intel_agp agpgart ext2
CPU: 0
EIP: 0060:[<00000000>] Tainted: P VLI
EFLAGS: 00010246 (2.6.15)
EIP is at rest_init+0x3feffd68/0x20
eax: 00000000 ebx: f8bb6280 ecx: 00000000 edx: 00000206
esi: b7faf000 edi: f0435000 ebp: f0435000 esp: f0435fa0
ds: 007b es: 007b ss: 0068
Process insmod (pid: 6290, threadinfo=f0435000 task=f71d3030)
Stack: f8bb600e f8bb6020 c0130bc1 0804b018 b7faf000 08048514 c01026e3 0804b018
000008bb 0804b008 b7faf000 08048514 bfbc17e8 00000080 0000007b c010007b
00000080 ffffe410 00000073 00000246 bfbc1770 0000007b 5a5a5a5a a55a5a5a
Call Trace:
[<f8bb600e>] null_init+0xe/0x20 [kernel]
[<c0130bc1>] sys_init_module+0xe4/0x1f7
[<c01026e3>] sysenter_past_esp+0x54/0x75
Code: Bad EIP value.
Either this really does not work, or I am doing something wrong. :)
Should I try to call the mmap syscall directly?
I can try this on ppc32, too.
--
Greetings Michael.
On Feb 24, 2006, at 06:37:21, Michael Buesch wrote:
> I am playing around with it. I did the attached code. It is a
> usermode program, which tries to map NULL, and a kernel module,
> which calls a NULL pointer. The file badcode.bin contains an i386
> ud2 instruction. When loading the kernel module, while the usermode
> program is executing, I get the usual NULL pointer dereference oops:
You need to trigger the null pointer dereference from within the
userspace program that maps NULL. The reason your test doesn't do
anything is that it is the insmod tool whose address space gets used,
as opposed to your nulltest program.
Cheers,
Kyle Moffett
>> I am playing around with it. I did the attached code. It is a usermode
>> program, which tries to map NULL, and a kernel module, which calls a NULL
>> pointer. The file badcode.bin contains an i386 ud2 instruction. When
>> loading the kernel module, while the usermode program is executing, I get
>> the usual NULL pointer dereference oops:
>
> You need to trigger the null pointer dereference from within the userspace
> program that maps NULL. The reason your test doesn't do anything is that it is
> the insmod tool whose address space gets used, as opposed to your nulltest
> program.
>
Think of a device driver which dereferences on read() or write() or ioctl.
Then the userspace program gets its chance, does not it?
Jan Engelhardt
--