Re: advanced buffer overflow study

Il dom, 2003-04-13 alle 18:14, Angelo Dell'Aera ha scritto:

> Ho  condotto  qualche  indagine  su   abo8.c  e  sembra  che  non  sia
> exploitabile o almeno  non in maniera standard. Inoltre,  la causa del
> segmentation  fault  sembrerebbe nient'altro  che  una violazione  dei
> limiti di pagina.  Infatti, dando un'occhiata  al codice  della strcpy 
> (preso dalle glibc-2.2.5), si legge questo.

ciao,
il problema risiede nel fatto che nella bss non c'e' nulla se il binario
viene compilato linkando dinamicamente le librerie (libc).

[root@pc999 src]# objdump abo8.shared --syms|grep bss
080494c0 l    d  .bss	00000000              
080494c0 l     O .bss	00000001              completed.1
080494bc g       *ABS*	00000000              __bss_start
080494e0 g     O .bss	00000100              buf

cioe', come giustamente dice Angelo, non vado a sovrascrivere proprio
niente di utile.

mentre se compilo staticamente con :
[root@pc999 src]# gcc -static abo8.c -o abo8.static
[root@pc999 src]# objdump abo8.static --syms|sort -k 1 |grep bss
....snip......
080a9660 g     O .bss	00000100 buf
080a9760 g     O .bss	00000004 __libc_tsd_MALLOC_data
080a9764 g     O .bss	00000004 __have_no_fcntl64
080a9768 g     O .bss	00000004 __libc_internal_tsd_set
080a976c g     O .bss	00000004 __libc_internal_tsd_get
080a9770 g     O .bss	00000004 _dl_clktck
080a9774 g     O .bss	00000004 _dl_init_all_dirs
080a9778 g     O .bss	00000004 _dl_initfirst
080a977c g     O .bss	00000004 _dl_all_dirs
080a9780 g     O .bss	00000004 _dl_osversion
080a9784 g     O .bss	00000004 _dl_pagesize
080a9788 g     O .bss	00000004 _dl_num_relocations
080a9790 g     O .bss	00000004 _dl_nloaded
080a9794 g     O .bss	00000004 __libc_stack_end
080a9798 g     O .bss	00000008 _dl_initial_searchlist
080a97a0 g     O .bss	00000004 _dl_platformlen
080a97a4 g     O .bss	00000004 _dl_debug_mask
080a97a8 g     O .bss	00000004 _dl_profile
080a97b0 g     O .bss	00000008 _dl_cpuclock_offset
080a97b8 g     O .bss	00000004 _dl_bind_not
080a97bc g     O .bss	00000004 _dl_platform
080a97c0 g     O .bss	00000004 _dl_lazy
080a97c4 g     O .bss	00000004 _dl_origin_path
080a97c8 g     O .bss	00000004 _dl_verbose
080a97cc g     O .bss	00000004 _dl_loaded
080a97d0 g     O .bss	00000004 _dl_profile_map
080a97d4 g     O .bss	00000004 _dl_inhibit_rpath
080a97d8 g     O .bss	00000004 _dl_search_paths
080a97dc g     O .bss	00000004 __libc_argc
080a97e0 g     O .bss	00000004 __libc_argv
080a97e8 g     O .bss	00000004 __libc_hp_timing_hwcap
080a97f0 g     O .bss	00000008 __libc_hp_timing_overhead
080a97f8 g     O .bss	00000004 __have_no_stat64
080a97fc g     O .bss	00000004 _nl_domain_bindings
080a9800 g     O .bss	00000004 _nl_msg_cat_cntr
080a9820 g     O .bss	00000400 __printf_arginfo_table
080a9c20 g     O .bss	00000004 __printf_function_table
080a9c24 g     O .bss	00000004 __gconv_modules_db
080a9c28 g     O .bss	00000004 __gconv_alias_db
080a9c2c g     O .bss	00000004 __gconv_path_envvar
080a9c30 g     O .bss	00000004 __gconv_max_path_elem_len
080a9c34 g     O .bss	00000004 __gconv_path_elem
080a9c38 g     O .bss	00000004 __gconv_cache
080a9c3c g     O .bss	00000018 __libc_setlocale_lock
080a9c60 g     O .bss	00000034 _nl_locale_file_list
080a9c94 g     O .bss	00000004 tzstring_list
080a9c98 g     O .bss	00000004 __tzname_cur_max
080a9c9c g     O .bss	00000004 __use_tzfile
080a9ca0 g     O .bss	00000004 __have_no_new_getrlimit
080a9cc0 g     O .bss	0000002c _tmbuf
080a9cec g     O .bss	00000004 _dl_num_cache_relocations
080a9cf0 g     O .bss	00000004 _dl_global_scope_alloc
080a9cf4 g     O .bss	00000014 _r_debug

in realta' (basta fare una ricerca su google) fino a qualche release fa
nella bss c'era una struttura che permetteva di exploitare il sorgente
in questione: __exit_funcs.
questa struttura viene chiamata dalla funzione atexit che lancia la
funzione exit (atexit exploiting).
Ora invece la struttura in questione si trova, facendo:

[root@pc999 src]# objdump abo8.static --syms|sort -k 1|grep exit
08048470 g     F .text	000000b7 exit
08048530 g     F .text	0000010a __cxa_atexit
08048640 g     F .text	000000dd __new_exitfn
08050bc0 g     F .text	0000001a _exit
080a5c68 g       *ABS*	00000000 __start___libc_atexit
080a5c68 l    d  __libc_atexit	00000000 
080a5c68 l     O __libc_atexit	00000004
__elf_set___libc_atexit_element__cleanup__
080a5c6c g       *ABS*	00000000 __stop___libc_atexit
080a6c8c g     O .data	00000004 __exit_funcs <<<<<<<<<<<<<<<<


nella sezione .data che e' un po' piu' su di buf e non si puo'
ovviamente sovrascrivere con buf.

Se su una redhat 6.2 si puo' exploitare sovrascrivendo le
__exit_funcs,le strutture che attualmente si possono sovrascrivere sono
quelle al di sotto di buf e quindi (forse?) nessuna utile per un
sorgente cosi' semplice...

chissa' che non si riesca lo stesso ma ne dubito, anche se non ho
approfondito piu' di cosi'.

bye stefano

pre-ps. scusate per la mail eccessivamente lunga.
ps. Forse la discussione dovrebbe andare in devel@





________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List