SILC Client version 1.1.18 was released mentioning a format string flaw fix in its changelog: http://silcnet.org/docs/changelog/SILC%20Client%201.1.8 Fixed string format vulnerability in client entry handling. Reported and patch provided by William Cummings. Affected code is also included in libsilc 1.1.18. Upstream commit: http://git.silcnet.org/gitweb/?p=silc.git;a=commitdiff;h=1598b3a51b51a434037461ccd35487bc0df3137c I have not looked if this is remotely exploitable or can only be triggered by local user setting odd nick. Upstream commit use term "vulnerability", so probably remote. In Fedora, we usually do not need to worry much about format string flaws any more, as glibc hardening / FORTIFY_SOURCE catches this type of flaw (reduces impact to controlled abort only). SILC, however, seems to provide it's own snprintf implementation, which is likely to not benefit from glibc protections (I've not verified though): http://git.silcnet.org/gitweb/?p=runtime.git;a=blob;f=lib/silcutil/silcsnprintf.c Affected code was introduced via following upstream commits in 2007: http://git.silcnet.org/gitweb/?p=silc.git;a=commitdiff;h=24044237b5a291b34afbc253406e7117f7c7a63e http://git.silcnet.org/gitweb/?p=silc.git;a=commitdiff;h=bb7b74bba3baa4ab2777536b2f3424efd09d9c4f It is not part of libsilc as shipped in Red Hat Enterprise Linux 4 and 5. References: http://www.vuxml.org/freebsd/4e306850-811f-11de-8a67-000c29a67389.html
libsilc-1.1.8-5.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/libsilc-1.1.8-5.fc10
libsilc-1.1.8-5.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/libsilc-1.1.8-5.fc11
More format string issues got fixed in SILC Toolkit 1.1.10: http://silcnet.org/docs/changelog/SILC%20Toolkit%201.1.10 More string format fixes in silcd and client libary Relevant patch: http://git.silcnet.org/gitweb/?p=silc.git;a=commitdiff;h=8cb801cf6482666818e721822ce81c81ec818908 libsilc shipped in Fedora / Red Hat Enterprise Linux only contains SILC libraries and not client and server, first part of the commit fixing issue in silcd does not apply. Second part, lib/silcclient/command.c, is applicable to libsilc-1.1.8 packages in Fedora. As with one of the previous issues, this problem was introduced in 2007 via following commit: http://git.silcnet.org/gitweb/?p=silc.git;a=commitdiff;h=bb7b74bba3baa4ab2777536b2f3424efd09d9c4f and hence this does not affect libsilc packages in Red Hat Enterprise Linux 4 and 5.
libsilc updates currently in F10 and F11 testing seems to need respin.
libsilc-1.1.8-7.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/libsilc-1.1.8-7.fc11
libsilc-1.1.8-7.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/libsilc-1.1.8-7.fc10
libsilc-1.1.8-7.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
libsilc-1.1.8-7.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
Thank you!
Despite initial indication, this got two CVEs after all: CVE-2009-3051: Multiple format string vulnerabilities in lib/silcclient/client_entry.c in Secure Internet Live Conferencing (SILC) Toolkit before 1.1.10, and SILC Client before 1.1.8, allow remote attackers to execute arbitrary code via format string specifiers in a nickname field, related to the (1) silc_client_add_client, (2) silc_client_update_client, and (3) silc_client_nickname_format functions. -> this is for comment #0 issues CVE-2009-3163: Multiple format string vulnerabilities in lib/silcclient/command.c in Secure Internet Live Conferencing (SILC) Toolkit before 1.1.10, and SILC Client 1.1.8 and earlier, allow remote attackers to execute arbitrary code via format string specifiers in a channel name, related to (1) silc_client_command_topic, (2) silc_client_command_kick, (3) silc_client_command_leave, and (4) silc_client_command_users. -> this is for (client part of the) comment #3 issues http://thread.gmane.org/gmane.comp.security.oss.general/2046/focus=2095