FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 11-30-2009, 10:47 PM
Adrien Kunysz
 
Default fuzzing crash(8)

Earlier today I was pointed to a truncated vmcore that made crash(8) crash and this prompted me to do some fuzzing.
Before going further I would like to know if there is interest to fix this kind of bugs and if I should report them to
Bugzilla. After all, most of these crashes are unlikely to happen in real life as long as the vmcores have not been
purposefully tempered with.


The most common crash by far in my tests is this one:

Consider a x86_64 vmcore file taken with the snap plugin:

00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 |..>.............|
00000020 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |@...............|
00000030 00 00 00 00 40 00 38 00 03 00 00 00 00 00 00 00 |....@.8.........|
00000040 04 00 00 00 00 00 00 00 e8 00 00 00 00 00 00 00 |................|

If we change byte 0x4e:

00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 |..>.............|
00000020 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |@...............|
00000030 00 00 00 00 40 00 38 00 03 00 00 00 00 00 00 00 |....@.8.........|
00000040 04 00 00 00 00 00 00 00 e8 00 00 00 00 00 80 00 |................|

This makes crash(8) segfault:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004f1bf4 in dump_Elf64_Nhdr (offset=36028797018964200, store=1) at netdump.c:1807
1807 notesize = (uint64_t)note->n_namesz + (uint64_t)note->n_descsz;
(gdb) bt full
#0 0x00000000004f1bf4 in dump_Elf64_Nhdr (offset=36028797018964200, store=1) at netdump.c:1807
i = 0
lf = 0
words = 0
note = (Elf64_Nhdr *) 0x800000159520c8
len = 140737175810672
buf = '' <repeats 1499 times>
ptr = 0x800000159520d4 <Address 0x800000159520d4 out of bounds>
uptr = (ulonglong *) 0x100000000
iptr = (int *) 0x0
up = (ulong *) 0x6f0617
xen_core = 0
vmcoreinfo = 0
remaining = 0
notesize = 362094736
#1 0x00000000004ed99a in is_netdump (file=0x7fffed5f1bee "vmcore-sample-small.x86_64",
source_query=128) at netdump.c:335
i = 2
fd = 6
swap = 0
elf32 = (Elf32_Ehdr *) 0x7fffed5ef8b0
load32 = (Elf32_Phdr *) 0x0
elf64 = (Elf64_Ehdr *) 0x7fffed5ef8b0
load64 = (Elf64_Phdr *) 0x7fffed5ef928
eheader = [...]
buf = [...]
size = 760
len = 0
tot = 0
offset32 = 32767
offset64 = 36028797018964200
tmp_flags = 64
tmp_elf_header = 0x15951fe0 "177ELF020101"
#2 0x00000000004f3e3b in is_kdump (file=0x7fffed5f1bee "vmcore-sample-small.x86_64", source_query=128)
at netdump.c:2383
No locals.
#3 0x000000000044c892 in main (argc=2, argv=0x7fffed5f0cb8) at main.c:401
i = <value optimized out>
c = <value optimized out>
option_index = 0

It looks like it should do more sanity check on p_offset but I am unsure how to fix this properly.

This is crash-4.1.1-0. The sample vmcore is too large to send by mail or to attach to Bugzilla and I am not sure the
crash core itself would be of much use.


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 12-01-2009, 01:27 PM
Dave Anderson
 
Default fuzzing crash(8)

----- "Adrien Kunysz" <adk@redhat.com> wrote:

> Earlier today I was pointed to a truncated vmcore that made crash(8)
> crash and this prompted me to do some fuzzing.
> Before going further I would like to know if there is interest to fix
> this kind of bugs and if I should report them to
> Bugzilla. After all, most of these crashes are unlikely to happen in
> real life as long as the vmcores have not been
> purposefully tempered with.

Exactly. So let's just fix it.

>
> The most common crash by far in my tests is this one:
>
> Consider a x86_64 vmcore file taken with the snap plugin:
>
> 00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
> 00000010 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 |..>.............|
> 00000020 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |@...............|
> 00000030 00 00 00 00 40 00 38 00 03 00 00 00 00 00 00 00 |....@.8.........|
> 00000040 04 00 00 00 00 00 00 00 e8 00 00 00 00 00 00 00 |................|
>
> If we change byte 0x4e:
>
> 00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
> 00000010 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 |..>.............|
> 00000020 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |@...............|
> 00000030 00 00 00 00 40 00 38 00 03 00 00 00 00 00 00 00 |....@.8.........|
> 00000040 04 00 00 00 00 00 00 00 e8 00 00 00 00 00 80 00 |................|
>
> This makes crash(8) segfault:
>

Right -- I can see that when you hand-set the PT_NOTE segment's p_offset field
to some bizarre value, it caused a reference outside of the 760-bye allocated
header. I presume that the fix would be to have dump_Elf64_Nhdr() return immediately
at line 1803, i.e. instead of setting "remaining" to 0 and then waiting until
making it to line 1809 to print the error message and then return.

Does that work?

Dave


> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004f1bf4 in dump_Elf64_Nhdr (offset=36028797018964200, store=1) at netdump.c:1807
> 1807 notesize = (uint64_t)note->n_namesz + (uint64_t)note->n_descsz;
> (gdb) bt full
> #0 0x00000000004f1bf4 in dump_Elf64_Nhdr (offset=36028797018964200, store=1) at netdump.c:1807
> i = 0
> lf = 0
> words = 0
> note = (Elf64_Nhdr *) 0x800000159520c8
> len = 140737175810672
> buf = '' <repeats 1499 times>
> ptr = 0x800000159520d4 <Address 0x800000159520d4 out of bounds>
> uptr = (ulonglong *) 0x100000000
> iptr = (int *) 0x0
> up = (ulong *) 0x6f0617
> xen_core = 0
> vmcoreinfo = 0
> remaining = 0
> notesize = 362094736
> #1 0x00000000004ed99a in is_netdump (file=0x7fffed5f1bee "vmcore-sample-small.x86_64", source_query=128) at netdump.c:335
> i = 2
> fd = 6
> swap = 0
> elf32 = (Elf32_Ehdr *) 0x7fffed5ef8b0
> load32 = (Elf32_Phdr *) 0x0
> elf64 = (Elf64_Ehdr *) 0x7fffed5ef8b0
> load64 = (Elf64_Phdr *) 0x7fffed5ef928
> eheader = [...]
> buf = [...]
> size = 760
> len = 0
> tot = 0
> offset32 = 32767
> offset64 = 36028797018964200
> tmp_flags = 64
> tmp_elf_header = 0x15951fe0 "177ELF020101"
> #2 0x00000000004f3e3b in is_kdump (file=0x7fffed5f1bee "vmcore-sample-small.x86_64", source_query=128) at netdump.c:2383
> No locals.
> #3 0x000000000044c892 in main (argc=2, argv=0x7fffed5f0cb8) at
> main.c:401
> i = <value optimized out>
> c = <value optimized out>
> option_index = 0
>
> It looks like it should do more sanity check on p_offset but I am
> unsure how to fix this properly.

I would guess that the
>
> This is crash-4.1.1-0. The sample vmcore is too large to send by mail
> or to attach to Bugzilla and I am not sure the
> crash core itself would be of much use.

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 12-01-2009, 02:24 PM
Dave Anderson
 
Default fuzzing crash(8)

----- "Dave Anderson" <anderson@redhat.com> wrote:

I did the same thing to a vmcore (i.e. handcrafting the PT_NOTE
segment's p_offset field like you did), and was able to get the
crash session up with the attached patch.

Does it work for you?

Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 12-01-2009, 06:27 PM
Adrien Kunysz
 
Default fuzzing crash(8)

Dave Anderson wrote:

----- "Dave Anderson" <anderson@redhat.com> wrote:

I did the same thing to a vmcore (i.e. handcrafting the PT_NOTE
segment's p_offset field like you did), and was able to get the
crash session up with the attached patch.

Does it work for you?


Thanks. I confirm crash(8) now exits cleanly when given the corrupted vmcore after applying the patch.

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 02:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org