Common Vulnerabilities and Exposures assigned an identifier CVE-2008-1552 to the following vulnerability: The silc_pkcs1_decode function in the silccrypt library (silcpkcs1.c) in Secure Internet Live Conferencing (SILC) Toolkit before 1.1.7, SILC Client before 1.1.4, and SILC Server before 1.1.2 allows remote attackers to execute arbitrary code via a crafted PKCS#1 message, which triggers an integer underflow, signedness error, and a buffer overflow. NOTE: the researcher describes this as an integer overflow, but CVE uses the "underflow" term in cases of wraparound from unsigned subtraction. Refences: http://www.securityfocus.com/archive/1/archive/1/490069/100/0/threaded http://www.coresecurity.com/?action=item&id=2206 http://silcnet.org/general/news/?item=client_20080320_1 http://silcnet.org/general/news/?item=server_20080320_1 http://silcnet.org/general/news/?item=toolkit_20080320_1 http://www.securityfocus.com/bid/28373 http://www.frsirt.com/english/advisories/2008/0974/references http://www.securitytracker.com/id?1019690 http://secunia.com/advisories/29463
Commit in upstream GIT: http://git.silcnet.org/gitweb/?p=silc.git;a=commitdiff;h=b36495161037e52ad993202da5d3df1837235d24
Fedora packages already fixed: https://admin.fedoraproject.org/updates/F7/FEDORA-2008-2616 https://admin.fedoraproject.org/updates/F8/FEDORA-2008-2641
Created attachment 303537 [details] Upstream patch (for posterity)
We won't be fixing this issue for Red Hat Enterprise Linux 4 and 5. This flaw can only result in the crash of the client (pidgin in this instance, nothing else uses libsilc). The flaw in question results in the following code: memcpy(dest_data, data + i, data_len - i); Where (data_len - i) = -1, that results in memcpy trying to copy a huge amount of memory, which will crash long before any arbitrary code execution is possible. The crash is only possible if a client connects to a malicious server. As this crash requires the user action to crash the application, we do not consider it to be a security flaw.
Closing, based on comment #2 and comment #4.
To clarify comment #4 a bit: When this flaw is exercised, (data_len - i) will always be -1, which means the memcpy call ends up being: memcpy(dest_data, data+i, -1) The size variable in this instance is of size_t type, which means this will translate into all addressable memory on the system. This makes the memcpy call impossible to return from.