heap corruption and missing boundary checks
CWE Classification: CWE-20, CWE-823, CWE-126, CWE-122
CVE-2016-7044  was assigned to bug 1
CVE-2016-7045  was assigned to bug 2
Gabriel Campana and Adrien Guinet from Quarkslab reported two remote
crash and heap corruption vulnerabilites in Irssi's format parsing
They also provided us with proof of concept exploit code and patches
to fix those issues.
Remote crash and heap corruption. Remote code execution seems
difficult since only Nuls are written.
Based on analysis Provided by Gabriel Campana and Adrien Guinet from
The unformat_24bit_color() function is called by format_send_to_gui()
to decode 24bit color codes into their components. The pointer is
advanced unconditionally without checking if a complete code was
Thus, after the return of unformat_24bit_color(), ptr might be invalid
and point out of the buffer.
The format_send_to_gui() function does not validate the length of the
string before incrementing the `ptr' pointer in all cases.
If that happens, the pointer `ptr' can be incremented twice and thus
end past the boundaries of the original `dup' buffer.
Irssi 0.8.17-beta up to and including 0.8.19 up to 0.8.19-219-g52fedea
Bug 1 affects only Irssis compiled with true-color enabled.
Bug 2 affects all Irssis regardless of compilation flags.
Upgrade to Irssi 0.8.20. Irssi 0.8.20 is a maintenance release
without any new features.
After installing the updated packages, one can issue the /upgrade
command to load the new binary. TLS connections will require
/reconnect. If the buf.pl script is loaded and symlinked into
~/.irssi/scripts/autorun, text buffer content will be saved and
Distributions which need to remain on Irssi 0.8.17 are strongly urged
to apply the patch and provide updated packages.
Those who cannot upgrade right now, but with Perl support enabled in
their Irssi, can load the following script and add it to
~/.irssi/scripts/autorun as a first aid to mitigating these issues:
arches, please quick stabilize =net-irc/irssi-0.8.20 for the bug
@security - Not sure if it should be A3 or B3
Stable on alpha.
Stable for HPPA PPC64.
Maintainer(s), please cleanup.
Security, please add it to the existing request, or file a new one.
I think it'd have made more sense to stabilise -r1 since it includes another fix for another CVE (including the fix for the current bug). See bug 595172.
Does someone mind if I mark -r1 stable via the ALLARCHES policy and clean up versions < -r1? so that we can kill two birds in one stone.
I've just ported the keyword and performed a cleanup.
No proofing of arbitrary code execution in this as mentioned by the CWE. Re-designating.
GLSA Vote: No