ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá














     áòèé÷ :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

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

[security-alerts] Perl format string integer wrap vulnerability



> Subject: Full-Disclosure Digest, Vol 10, Issue 2
> 

> Message: 5
> Date: Thu, 1 Dec 2005 01:03:47 -0800
> From: advisory@xxxxxxxxxxxxxxxx
> Subject: [Full-disclosure] Perl format string integer wrap
>       vulnerability
> To: full-disclosure@xxxxxxxxxxxxxxxxx
> Message-ID: <20051201090347.GH28337@xxxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=us-ascii
> 
> SUMMARY. perl suffers from an integer wrap overflow inside 
> the explicit
> parameter format string functionality, this has been confirmed to be a
> vector for remote code execution.
> 
> Date Found:   September 23, 2005.
> Public Release: TBD.
> Application:  perl
> Credit:       Jack Louis of Dyad Security
> 
> BACKGROUND.  perl is a cross-platform scripting language. for more
> details see Perl.org
> 
> DESCRIPTION.  Value over INT_MAX(value of I) inside explicit parameter
> format string (%I$n) causes integer wrap in the efix (32bit signed
> integer) variable inside the function Perl_sv_vcatpvfn (see example 1)
> (sv.c:~9360). Allowing for a write value anywhere in memory 
> exploitation
> vector (see example 2). Further, heap corruption itself is 
> possible (see
> example 3), as are more exotic non-reliable $PC redirection 
> (see example
> 4). From what we have seen the first exploitation method is the only
> valid one. ImmunitySec has found a generic method of controlling the
> first condition with a good amount of robustness and success. Perl
> itself is not directly vulnerable to remote attacks due to this flaw,
> however any perl program with format string vulnerabilities is. The
> vulnerability is not to limited DoS (as reported previously) 
> but remote
> code execution as well as information leakage and DoS.
> 
> IMPACT.  Perl itself is not generally impacted by this vulnerability,
> but programs with format string vulnerabilities (Dyad Security has
> confirmed that several programs available at this time have this
> specific issue) can be vulnerable to remote code execution. 
> Information
> about creating a robust generic exploit is forthcoming, so public
> knowledge of exploitation methods for this issue is in the cards.
> 
> AFFECTED VERSIONS.  Perl 5.9.2 and perl 5.8.6 have been 
> tested and found
> to be vulnerable on linux, freebsd, dragonflybsd on the ia32 platform.
> It is assumed that a much larger range of software and platforms are
> also affected, as the sv.c seems to remain seemingly static over time,
> however this is not confirmed.
> 
> EXAMPLE 1.  
> $ gdb myperl/bin/perl5.8.7
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public 
> License, and you are
> welcome to change it and/or distribute copies of it under 
> certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show 
> warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu"...Using host 
> libthread_db library "/lib/tls/libthread_db.so.1".
> 
> (gdb) break sv.c:9232
> Breakpoint 1 at 0x80c0df0: file sv.c, line 9232.
> (gdb) set args -e 'printf("%2147483647\$n");'
> (gdb) run
> 
> Breakpoint 1, Perl_sv_vcatpvfn (sv=0x812d180, pat=0x0, 
> patlen=0, args=0x0, svargs=0x8133080,
>     svmax=0, maybe_tainted=0xbffb72cb "") at sv.c:9232
> 9232    in sv.c
> (gdb) p efix
> $1 = 2147483647
> (gdb) set args -e 'printf("%2147483648\$n");'
> (gdb) run
> 
> Breakpoint 1, Perl_sv_vcatpvfn (sv=0x812d180,
>     pat=0x80000000 <Address 0x80000000 out of bounds>, 
> patlen=0, args=0x0, svargs=0x8133080,
>     svmax=0, maybe_tainted=0xbfb0640b "") at sv.c:9232
> 9232    in sv.c
> (gdb) p efix
> $2 = -2147483648
> (gdb) cont
> Modification of a read-only value attempted at -e line 1.
> 
> Program exited with code 0377.
> (gdb) set args -e 'printf("%2147483649\$n");'
> (gdb) run
> 
> Breakpoint 1, Perl_sv_vcatpvfn (sv=0x812d180,
>     pat=0x80000001 <Address 0x80000001 out of bounds>, 
> patlen=0, args=0x0, svargs=0x8133080,
>     svmax=0, maybe_tainted=0xbfe69b9b "") at sv.c:9232
> 9232    in sv.c
> (gdb) p efix
> $3 = -2147483647
> (gdb) cont
> 
> Program received signal SIGSEGV, Segmentation fault.
> Perl_sv_setiv (sv=0x0, i=0) at sv.c:1652
> 1652    in sv.c
> (gdb) bt
> #0  Perl_sv_setiv (sv=0x0, i=0) at sv.c:1652
> #1  0x080b6349 in Perl_sv_setuv_mg (sv=0x0, u=0) at sv.c:1743
> #2  0x080c0e06 in Perl_sv_vcatpvfn (sv=0x812d180,
>     pat=0x80000001 <Address 0x80000001 out of bounds>, 
> patlen=0, args=0x0, svargs=0x8133080,
>     svmax=0, maybe_tainted=0xbfe69b9b "") at sv.c:9232
> #3  0x080e923b in Perl_do_sprintf (sv=0x812d180, len=1, 
> sarg=0x813307c) at doop.c:713
> #4  0x080de48a in Perl_pp_prtf () at pp_sys.c:1489
> #5  0x080ad038 in Perl_runops_standard () at run.c:37
> #6  0x080615c7 in S_run_body (oldscope=1) at perl.c:2000
> #7  0x080613ff in perl_run (my_perl=0x812d008) at perl.c:1919
> #8  0x0805e61f in main (argc=3, argv=0xbfe69da4, 
> env=0xbfe69db4) at perlmain.c:98
> (gdb) x/i $eip
> 0x80b61a8 <Perl_sv_setiv+8>:    mov    0x8(%ebx),%edx
> (gdb) i r ebx edx
> ebx            0x0      0
> edx            0x812d180        135451008
> (gdb)
> 
> EXAMPLE 2.  
> #0  Perl_sv_setiv (sv=0x815f821, i=0) at sv.c:2184
> 2184        SvIVX(sv) = i;
> (gdb) x/i $eip
> 0x80c815c <Perl_sv_setiv+108>:  mov    %esi,0xc(%eax)
> 
> EXAMPLE 3.  
> #0  0xb7e69fb0 in malloc_consolidate () from /lib/tls/libc.so.6
> 
> EXAMPLE 4.  
> #0  0x09010e50 in ?? ()
> 
> FIXES.  Due to the information that has already been leaked 
> we moved up
> the release date of this advisory. There is no official fix for this
> issue as of yet. We have provided a sample patch for the 
> 5.9.2 version.
> 
> See http://www.dyadsecurity.com/perl-0002.html for additional 
> information and a link to the patch.
> 
> SPECIAL THANKS.
> Special thanks to Dave Aitel and Bas Alberts of ImmunitySec for the
> donation of resources and leading the difficult phase of exploit
> verification research. If you wish to obtain any exploits or further
> detailed information regarding this vulnerability, please contact
> ImmunitySec.
> 
> LEGAL NOTICES.  
> Copyright (C) 2005 Dyad Security, Inc.
> 
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without the express
> written consent of Dyad Security, Inc. If you wish to reprint 
> the whole
> or any part of this alert in any other medium other than 
> electronically,
> please email advisoryreprint@xxxxxxxxxxxxxxxx for permission.
> 
> DISCLAIMER.  
> The information in the advisory is believed to be accurate at the time
> of publishing based on currently available information. Use of the
> information constitutes acceptance for use in an AS IS 
> condition. There
> are no warranties with regard to this information. Neither the author
> nor the publisher accepts any liability for any direct, indirect, or
> consequential loss or damage arising from use of, or reliance on, this
> information.
> 
> SEE ALSO.
> http://www.dyadsecurity.com/webmin-0001.html
> 
> 




 




Copyright © Lexa Software, 1996-2009.