Multiple issues in p7zip
I reported several bugs discovered with afl in p7zip, the portable command line version of the 7-Zip archiving tool, one null pointer access causing a segfault and one out of bounds heap read.
At the time I reported the first issues these were already fixed in the main 7-Zip code, but the portable version hadn't been updated yet. Now there is version 16.02, unfortunately there are still issues left.
Null pointer access / segfault
An access to a null pointer in NArchive::N7z::CStreamSwitch::Set can cause p7zip to crash.
Out of bounds read (bug is not publicly visible yet)
An out of bounds heap read access can happen in the function NArchive::N7z::CDecoder::Decode.
Null pointer acctess / segfault (unfixed in 16.02)
A memory allocation isn't checked for a failing allocation. If the file's header indicates a large data size the allocation will fail and subsequently p7zip will try to write to a null pointer. This will likely only lead to a crash and not to further security issues, however this problem seems prevalent in the 7-zip codebase - there are several memory allocations without a check for failures.
p7zip is often used in security appliances to scan inputs, because it supports a large number of archiving file formats. Vulnerabilities in it have played a role in previous attacks on Fireeye appliances. Therefore it's worrying that it's so easy to find crashers in it via fuzzing.
There were also other issues in 7-Zip discovered lately.
At the time I reported the first issues these were already fixed in the main 7-Zip code, but the portable version hadn't been updated yet. Now there is version 16.02, unfortunately there are still issues left.
Null pointer access / segfault
An access to a null pointer in NArchive::N7z::CStreamSwitch::Set can cause p7zip to crash.
Out of bounds read (bug is not publicly visible yet)
An out of bounds heap read access can happen in the function NArchive::N7z::CDecoder::Decode.
Null pointer acctess / segfault (unfixed in 16.02)
A memory allocation isn't checked for a failing allocation. If the file's header indicates a large data size the allocation will fail and subsequently p7zip will try to write to a null pointer. This will likely only lead to a crash and not to further security issues, however this problem seems prevalent in the 7-zip codebase - there are several memory allocations without a check for failures.
p7zip is often used in security appliances to scan inputs, because it supports a large number of archiving file formats. Vulnerabilities in it have played a role in previous attacks on Fireeye appliances. Therefore it's worrying that it's so easy to find crashers in it via fuzzing.
There were also other issues in 7-Zip discovered lately.