1.FreeImage-3.18 LibOpenJpeg/j2k.c file memcpy function Out-of-bounds
A out-of-bounds in line '3643' of the 'j2k_read_ppm_v3' function. Where the value of 'l_N_ppm' comes from the file read in, and occurs out-of-bounds when 'l_N_ppm' is greater than the size of p_header_data.
2.FreeImage-3.18 PluginTIFF.cpp file load function heap overflow vulnerability
When the program reads a tiff file, it will be handed to the Load function of the 'PluginTIFF.cpp' file, but in the '2074' line of the program, when the 'memcpy' function is executed, the destination address and the size of the copied data are not considered, resulting in heap overflow.
In the code above, we can see that 'dst_bits' comes from 'bits+rowSize' , In first round of the loop , the 'rowSize' is 0 , so the value of 'dst_bits' is the bits, and the bits is the return pointer of the 'FreeImage_GetScanLine' function
When the 'height' parameter is 1 , we see that the actual returned pointer is the return value of the 'FreeImage_GetBits' function
However,when I look at the documentation and the code of the 'FreeImage_GetBits' function, I still don't find that the returned pointer has a complete stack structure. Which makes dst_bits is like a magic address.
In fact, it is found through debugging that this address is in the heap space , but when the src_line is large enough, it will cause the coverage of the adjacent heap.
The sample of the crash is in the attachment, the name is heap-buff-overflow.tiff
3.A stack buff overflower on line 1284 at PluginTIFF.cpp
When reading a tiff file, the program will call the load function in 'PluginTIFF.cpp', In the '2251' line of the 'load' function, the program will call the 'ReadThumbnail' function.
Entering the 'ReadThumbnail' function, we see that the 'load' function is called again on line '1288'. However, the decision to determine the recursion is based on the return value of the 'TIFFSetSubDirectory' function.
In fact, the function that determines the return value of TIFFSetSubDirectory is the result of the 'TIFFReadDirectory' function.But under some special conditions, the 'TIFFReadDirectory' function always returns 1, which will cause the program stack space to be filled.
The following is a concrete example, which causes program memory corruption, which can lead to remote denial of service by attackers.
The sample of the crash is in the attachment, the name is stack-overflow.tiff
1.FreeImage-3.18 LibOpenJpeg/j2k.c file memcpy function Out-of-bounds
A out-of-bounds in line '3643' of the 'j2k_read_ppm_v3' function. Where the value of 'l_N_ppm' comes from the file read in, and occurs out-of-bounds when 'l_N_ppm' is greater than the size of p_header_data.
2.FreeImage-3.18 PluginTIFF.cpp file load function heap overflow vulnerability
When the program reads a tiff file, it will be handed to the Load function of the 'PluginTIFF.cpp' file, but in the '2074' line of the program, when the 'memcpy' function is executed, the destination address and the size of the copied data are not considered, resulting in heap overflow.
In the code above, we can see that 'dst_bits' comes from 'bits+rowSize' , In first round of the loop , the 'rowSize' is 0 , so the value of 'dst_bits' is the bits, and the bits is the return pointer of the 'FreeImage_GetScanLine' function
When the 'height' parameter is 1 , we see that the actual returned pointer is the return value of the 'FreeImage_GetBits' function
However,when I look at the documentation and the code of the 'FreeImage_GetBits' function, I still don't find that the returned pointer has a complete stack structure. Which makes dst_bits is like a magic address.
In fact, it is found through debugging that this address is in the heap space , but when the src_line is large enough, it will cause the coverage of the adjacent heap.
The sample of the crash is in the attachment, the name is heap-buff-overflow.tiff
3.A stack buff overflower on line 1284 at PluginTIFF.cpp
When reading a tiff file, the program will call the load function in 'PluginTIFF.cpp', In the '2251' line of the 'load' function, the program will call the 'ReadThumbnail' function.
Entering the 'ReadThumbnail' function, we see that the 'load' function is called again on line '1288'. However, the decision to determine the recursion is based on the return value of the 'TIFFSetSubDirectory' function.
In fact, the function that determines the return value of TIFFSetSubDirectory is the result of the 'TIFFReadDirectory' function.But under some special conditions, the 'TIFFReadDirectory' function always returns 1, which will cause the program stack space to be filled.
The following is a concrete example, which causes program memory corruption, which can lead to remote denial of service by attackers.
The sample of the crash is in the attachment, the name is stack-overflow.tiff
The internal FreeImage issues (the last two) are fixed in trunk. Examples no longer crash.
Last edit: Mihail Naydenov 2021-01-23