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 12-01-2009, 09:05 PM
Adrien Kunysz
 
Default fuzzing crash(8)

Adrien Kunysz wrote:

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.


Actually that patch fixes all the crashes I found with my previous round of black box fuzzing on x86_64 (using zzuf if
anyone is interested). I am currently playing with bunny (http://code.google.com/p/bunny-the-fuzzer/) but I am a bit
doubtful it will find anything useful in any decent amount of time without some manual work, oh well CPU time is cheap


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

Adrien Kunysz wrote:
Actually that patch fixes all the crashes I found with my previous round
of black box fuzzing on x86_64 (using zzuf if anyone is interested). I
am currently playing with bunny
(http://code.google.com/p/bunny-the-fuzzer/) but I am a bit doubtful it
will find anything useful in any decent amount of time without some
manual work, oh well CPU time is cheap


I wasn't expecting Bunny to find anything for a few days but it only took
about three hours

If we take the same x86_64 vmcore again:

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 80 00 00 00 00 00 00 |....@.8.........|

and mess a bit with byte 0x39:

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.........|

Program received signal SIGSEGV, Segmentation fault.
dump_Elf64_Phdr (prog=0x7410fd8, store_pt_load_data=2193) at netdump.c:1456
1456 pls->zero_fill = (prog->p_filesz == prog->p_memsz) ?
(gdb) p prog
$1 = (Elf64_Phdr *) 0x7410fd8
(gdb) p *prog
Cannot access memory at address 0x7410fd8
(gdb) bt full
#0 dump_Elf64_Phdr (prog=0x7410fd8, store_pt_load_data=2193) at netdump.c:1456
others = <value optimized out>
pls = (struct pt_load_segment *) 0x2aec420c9210
#1 0x00000000004f1b9d in is_netdump (file=0x7fffdda29c03 "bit456", source_query=<value optimized out>)
at netdump.c:332
i = 2193
fd = <value optimized out>
swap = <value optimized out>
load32 = (Elf32_Phdr *) 0x0
load64 = (Elf64_Phdr *) 0x7fffdda27348
eheader = [...]
buf = [...]
size = 760
len = <value optimized out>
tot = <value optimized out>
offset32 = <value optimized out>
offset64 = <value optimized out>
tmp_flags = 64
tmp_elf_header = <value optimized out>
#2 0x000000000044c852 in main (argc=2, argv=0x7fffdda28668) at main.c:401
i = <value optimized out>
c = <value optimized out>
option_index = 0
(gdb) up
#1 0x00000000004f1b9d in is_netdump (file=0x7fffdda29c03 "bit456", source_query=<value optimized out>)
at netdump.c:332
332 dump_Elf64_Phdr(nd->load64 + i, ELFSTORE+i);
(gdb) list
327 if (DUMPFILE_FORMAT(nd->flags) == NETDUMP_ELF64)
328 nd->page_size = (uint)nd->load64->p_align;
329 dump_Elf64_Ehdr(nd->elf64);
330 dump_Elf64_Phdr(nd->notes64, ELFREAD);
331 for (i = 0; i < nd->num_pt_load_segments; i++)
332 dump_Elf64_Phdr(nd->load64 + i, ELFSTORE+i);
333 offset64 = nd->notes64->p_offset;
334 for (tot = 0; tot < nd->notes64->p_filesz; tot += len) {
335 if (!(len = dump_Elf64_Nhdr(offset64, ELFSTORE)))
336 break;

I guess it means we need more sanity check on num_pt_load_segments
(and I need to read the ELF specs).

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

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

> Adrien Kunysz wrote:
> > Actually that patch fixes all the crashes I found with my previous round
> > of black box fuzzing on x86_64 (using zzuf if anyone is interested). I
> > am currently playing with bunny
> > (http://code.google.com/p/bunny-the-fuzzer/) but I am a bit doubtful it
> > will find anything useful in any decent amount of time without some
> > manual work, oh well CPU time is cheap
>
> I wasn't expecting Bunny to find anything for a few days but it only took
> about three hours
>
> If we take the same x86_64 vmcore again:
>
> 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 80 00 00 00 00 00 00 |....@.8.........|
>
> and mess a bit with byte 0x39:
>
> 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.........|
>
> Program received signal SIGSEGV, Segmentation fault.
> dump_Elf64_Phdr (prog=0x7410fd8, store_pt_load_data=2193) at
> netdump.c:1456
> 1456 pls->zero_fill = (prog->p_filesz == prog->p_memsz) ?
> (gdb) p prog
> $1 = (Elf64_Phdr *) 0x7410fd8
> (gdb) p *prog
> Cannot access memory at address 0x7410fd8
> (gdb) bt full
> #0 dump_Elf64_Phdr (prog=0x7410fd8, store_pt_load_data=2193) at
> netdump.c:1456
> others = <value optimized out>
> pls = (struct pt_load_segment *) 0x2aec420c9210
> #1 0x00000000004f1b9d in is_netdump (file=0x7fffdda29c03 "bit456",
> source_query=<value optimized out>)
> at netdump.c:332
> i = 2193
> fd = <value optimized out>
> swap = <value optimized out>
> load32 = (Elf32_Phdr *) 0x0
> load64 = (Elf64_Phdr *) 0x7fffdda27348
> eheader = [...]
> buf = [...]
> size = 760
> len = <value optimized out>
> tot = <value optimized out>
> offset32 = <value optimized out>
> offset64 = <value optimized out>
> tmp_flags = 64
> tmp_elf_header = <value optimized out>
> #2 0x000000000044c852 in main (argc=2, argv=0x7fffdda28668) at
> main.c:401
> i = <value optimized out>
> c = <value optimized out>
> option_index = 0
> (gdb) up
> #1 0x00000000004f1b9d in is_netdump (file=0x7fffdda29c03 "bit456",
> source_query=<value optimized out>)
> at netdump.c:332
> 332 dump_Elf64_Phdr(nd->load64 + i,
> ELFSTORE+i);
> (gdb) list
> 327 if (DUMPFILE_FORMAT(nd->flags) ==
> NETDUMP_ELF64)
> 328 nd->page_size =
> (uint)nd->load64->p_align;
> 329 dump_Elf64_Ehdr(nd->elf64);
> 330 dump_Elf64_Phdr(nd->notes64, ELFREAD);
> 331 for (i = 0; i < nd->num_pt_load_segments;
> i++)
> 332 dump_Elf64_Phdr(nd->load64 + i,
> ELFSTORE+i);
> 333 offset64 = nd->notes64->p_offset;
> 334 for (tot = 0; tot < nd->notes64->p_filesz; tot
> += len) {
> 335 if (!(len = dump_Elf64_Nhdr(offset64,
> ELFSTORE)))
> 336 break;
>
> I guess it means we need more sanity check on num_pt_load_segments
> (and I need to read the ELF specs).

I'm curious how "readelf -a" handle it?

I can't afford much time to look at these kinds of bugs at this
point in time. Quite frankly, if somebody's purposely corrupting
vmcore file headers, it doesn't really bother me all that much if
it causes a segmentation violation -- especially if the vmcore is
going to be unusable anyway.

Anyway, let me know when you've got a patch ready for this one... ;-)

Dave

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

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

> ----- "Adrien Kunysz" <adk@redhat.com> wrote:
>
> > Adrien Kunysz wrote:
> > > Actually that patch fixes all the crashes I found with my previous round
> > > of black box fuzzing on x86_64 (using zzuf if anyone is interested). I
> > > am currently playing with bunny
> > > (http://code.google.com/p/bunny-the-fuzzer/) but I am a bit doubtful it
> > > will find anything useful in any decent amount of time without some
> > > manual work, oh well CPU time is cheap
> >
> > I wasn't expecting Bunny to find anything for a few days but it only took
> > about three hours
> >
> > If we take the same x86_64 vmcore again:
> >
> > 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 80 00 00 00 00 00 00 |....@.8.........|
> >
> > and mess a bit with byte 0x39:
> >
> > 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.........|

You've got the two dumps above backwards, but as it turns out, a manual corruption
of the ELF header's e_phnum field should be pretty easy to handle -- try the attached
patch.

Thanks,
Dave

--
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 05:13 PM.

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