Bug 440049 - (CVE-2008-1552) CVE-2008-1552 libsilc: buffer overflow in PKCS#1 message decoding
CVE-2008-1552 libsilc: buffer overflow in PKCS#1 message decoding
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 438382
  Show dependency treegraph
Reported: 2008-04-01 10:56 EDT by Tomas Hoger
Modified: 2008-05-12 13:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-24 03:19:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Upstream patch (for posterity) (1.31 KB, patch)
2008-04-23 15:09 EDT, Josh Bressers
no flags Details | Diff

  None (edit)
Description Tomas Hoger 2008-04-01 10:56:06 EDT
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.

Comment 3 Josh Bressers 2008-04-23 15:09:23 EDT
Created attachment 303537 [details]
Upstream patch (for posterity)
Comment 4 Josh Bressers 2008-04-23 15:24:25 EDT
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.
Comment 5 Tomas Hoger 2008-04-24 03:19:26 EDT
Closing, based on comment #2 and comment #4.
Comment 6 Josh Bressers 2008-05-12 13:16:00 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.