Re: buffer overflow in bladeenc

[Powertech <powertech () ezkracho com ar>]

-----BEGIN PGP SIGNED MESSAGE-----

Bladeenc
in http://www.ezkracho.com.ar/src/exploits/index.html u can finda
a proof of concept exploit develop by polos () ezkracho com ar
cheers

> Hello everybody,
>
> Some time ago I discovered a buffer overflow vulnerability in bladeenc.
>
> Bladeenc is an open source mp3 encoder, widely used under linux.
>
> The program segfaults when a large string is given as argument on program
> startup. Under normal conditions, the syntax of bladeenc is like :
>
> bladeenc filename.wav
>
> If you change 'filename.wav' with a large string (around 300 chars),
> bladeenc crashes, overwriting %eip. Also, other options which can be
> specified trough argv[] can be exploited too. (I guess that the problem can
> be found in the argument parsing functions of the program - I didn't have
> much time to investigate the source, but a brief grep strcpy of the source
> gives few lines of output which may be useful)
>
> Bellow is a shot of what happens :
>
> [pesho@dingo stack]$ bladeenc `perl -e "print 'a' x 300"`
> Segmentation fault (core dumped)
> [pesho@dingo stack]$ gdb bladeenc core
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> ........
> Loaded symbols for /lib/ld-linux.so.2
> #0  0x41414141 in ?? ()
> (gdb) info reg
> eax            0x41414141       1094795585
> ecx            0x12c    300
> edx            0xbffffa00       -1073743360
> ebx            0x41414141       1094795585
> esp            0xbfffe470       0xbfffe470
> ebp            0x41414141       0x41414141   <---
> esi            0x41414141       1094795585   <---
> edi            0x41414141       1094795585   <---
> eip            0x41414141       0x41414141    <--- here we are ...
> eflags         0x10216  66070
> cs             0x23     35
> ss             0x2b     43
> ds             0x2b     43
> es             0x2b     43
> fs             0x2b     43
> gs             0x2b     43
> fctrl          0x37f    895
> fstat          0x0      0
> ftag           0xffff   65535
> fiseg          0x23     35
> fioff          0x804a34a        134521674
> foseg          0x2b     43
> fooff          0xbfffe4d8       -1073748776
> fop            0x59d    1437
> (gdb)
>
> So, as you see, the overflow is exploitable. I am not going to post
> an exploit to it, although very basic standard shellcode works against it.
>
> The overflow isn't really a security hole, since the binary isn't setuid.
> However, looking around with google, there are few systems that use
> bladeenc for some kind of 'distributed mp3 encoding'. They apparently
> consist of different daemons exchanging parts of audio and encoding them
> with bladeenc. There are few of those systems that could possibly be
> explited (and probably REMOTELY) using this overflow.
>
> Maybe someone on the list would like to test such systems and do some more
> research on the 'vulnerability'.
>
> For people who would like to test, standard shellcode from 'smashing the
> stack ...' should do the job.
>
> The author has been informed around two months ago - no answer received.
> At the time of the tests, the last stable version was still vulnerable - I
> don't know if the version has changed since.
>
> Thank you all.
>
> Peter

--
If you are a police dog, where's your badge?
                -- Question James Thurber used to drive his German Shepherd
                   crazy.


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: 6E8lr8/egigcEjshE3UM68UXaaTtfRlT

iQEVAwUBPHPNNYhDjf2eob5RAQFFoAf/Yj54qXa9pqUOsRkibR8EzOrCte5jQHhj
MXlHHops6r/h30N0MBCpYxttZJy3l074YX/0uK33gW1aGv/LRX5HWJH6qWO4jq2D
eiuoTQN0kjdV7x3Nvt8/x+95P4vJTNHHLcC/Jmx/FmqMbRzdNkFXY47q7JEcz2R3
2IBrMcvfoDphIvV57HOGnO3fhvtSJvbOhAMQk6pk23m29r8tkWOLSAUI+6GJxpbv
x1ntDKO7KWB+8DYixquQ8aPT9nRZgdaAFIWUQKAsqoWn7KkqT21oMKFLwKMg4ZSR
f1hazcuOcYyGmqk+BoiSxqlXRphZD7D1K8Elz+1Ec0xO8XTD0jXY/w==
=Remz
-----END PGP SIGNATURE-----