Bug#769606: Overflow a2p utility

[Damyan Ivanov]

Control: found -1 5.20.1-2
Control: tag -1 confirmed

-=| up201407890 at alunos.dcc.fc.up.pt, 14.11.2014 23:55:46 +0100 |=-
> Package: perl
> Version: 5

> Hello. My name is Federico Manuel Bento, and i have found what it 
> _appears_ to be a buffer overflow on the a2p (awk2perl)
> utility. It comes by default on several different systems.
> 
> Tested on Fedora 20, Fedora 19, Debian, and works probably on every
> UNIX-likes including BSD's, AIX, etc.
> 
> Eg:
> 
> [saken at zippy ~]$ python -c "print 'A' * 2048" | a2p >/dev/null
> [saken at zippy ~]$ python -c "print 'A' * 2049" | a2p >/dev/null
> [saken at zippy ~]$ python -c "print 'A' * 2050" | a2p >/dev/null
> Segmentation fault
> 
> OR
> 
> [saken at zippy ~]$ python -c "print 'A'*3000" > lel
> [saken at zippy ~]$ gdb a2p
> (gdb) r lel
> Starting program: /usr/bin/a2p lel
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000040b7c5 in yyparse ()
> (gdb) info reg
> rax            0x4141414141414141        8680820740569200760
> rbx            0x1        1
> rcx            0x0        0
> rdx            0x67d724        6805284
> rsi            0x67dab0        6806192
> rdi            0x41414141        2021161080
> rbp            0x6        0x6
> rsp            0x7fffffffe1d0        0x7fffffffe1d0
> r8             0x8        8
> r9             0x5f        95
> r10            0x0        0
> r11            0x38e0174b60        244277791584
> r12            0x6        6
> r13            0x0        0
> r14            0x0        0
> r15            0x0        0
> rip            0x40b7c5        0x40b7c5 <yyparse+757>
> eflags         0x10206        [ PF IF RF ]
> cs             0x33        51
> ss             0x2b        43
> ds             0x0        0
> es             0x0        0
> fs             0x0        0
> gs             0x0        0
> 
> [saken at zippy ~]$ uname -a
> Linux zippy 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2 x86_64 GNU/Linux
> [saken at zippy ~]$ dpkg -s libc6 | grep ^Version
> Version 2.13-38+deb7u6

I am able to reproduce this in current sid:

$ python -c "print 'A' * 2050" > h
$ gdb /usr/bin/a2p
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
…
Reading symbols from /usr/bin/a2p...Reading symbols from /usr/lib/debug//usr/bin/a2p...done.
done.
(gdb) r h
Starting program: /usr/bin/a2p h
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
yyparse () at y.tab.c:2880
2880    y.tab.c: no such file or directory
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7fcf700 (LWP 17464)):
#0  yyparse () at y.tab.c:2880
#1  0x0000000000400e8d in main (argc=<optimized out>, argv=0x7fffffffe670)
    at a2py.c:144
(gdb) 

If I am not mistaken, the actual source is:

   2883 { yyval = oper3(OBLOCK,oper2(OJUNK,yyvsp[-3],yyvsp[-2]),Nullop,yyvsp[0])
   2883 ; }
   2884 break;
   2885 #line 2878 "y.tab.c"
   2886     }
   2887     yyssp -= yym;
→  2888     yystate = *yyssp;
   2889     yyvsp -= yym;
   2890     yym = yylhs[yyn];


Can't find how y.tab.c is generated and what is its source.

yyssp seems to be a pointer to yyss[YYSTACKSIZE] the definition of 
YYSTACKSIZE escapes me.

Not much of a debugging, but I hope it gives some ideas to somebody 
else.


-- dam