Bug 468014 (CVE-2008-4619)
Summary: | CVE-2008-4619 libtirpc: rpcbind DoS in the taddr2uaddr XDR_DECODE | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Tomas Hoger <thoger> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | unspecified | CC: | steved |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-4619 | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-03-29 09:38:59 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tomas Hoger
2008-10-22 12:26:14 UTC
This also crashes rpcbind on Fedora and seems to be a libtirpc issue. In rpcb_service_4(), rpcbind calls libtirpc's xdr_netbuf() when taddr2uaddr decode is required. xdr_netbuf() first reads maxlen from the argument, later uses this as an upper bound while reading transport-encoded address to objp->buf using xdr_bytes() without further validation. However, malicious request from the PoC referenced above causes maxlen to be 0, which causes xdr_bytes() to return TRUE without initializing objp->buf. That is later used as inet_ntop argument, causing SEGV. Steve, can you please check whether I'm missing anything here? You also seem to be part of the libtirpc's upstream, can you let other libtirpc developers know about this issue, or should I try to contact them? Thanks! I've created upstream bug report for this: http://sourceforge.net/tracker/index.php?func=detail&aid=2192645&group_id=183075&atid=903784 I'm thinking the problem is not in xdr_netbuf() since its valid to return a zero length buffer. The problem is with the user of that zero length, in this case taddr2uaddr()->__rpc_taddr2uaddr_af() Here is the patch I propose: --- src/rpc_generic.c.orig 2008-10-27 10:04:32.000000000 -0400 +++ src/rpc_generic.c 2008-10-27 12:05:59.000000000 -0400 @@ -594,6 +594,9 @@ __rpc_taddr2uaddr_af(int af, const struc #endif u_int16_t port; + if (nbuf->len <= 0) + return NULL; + switch (af) { case AF_INET: sin = nbuf->buf; libtirpc-0.1.7-20.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/libtirpc-0.1.7-20.fc9 Fixed in libtirpc-0.1.9-6.fc10 Looks like this issue is bit older and was originally assigned CVE id CVE-2007-0165: Unspecified vulnerability in libnsl in Sun Solaris 8 and 9 allows remote attackers to cause a denial of service (crash) via malformed RPC requests that trigger a crash in rpcbind. References: http://www.securityfocus.com/bid/21964/ http://secunia.com/advisories/23700/ http://secunia.com/advisories/32403/ (In reply to comment #6) > Fixed in libtirpc-0.1.9-6.fc10 Steve, you've managed to typo NVR in the RPM changelog, as it now says 0.1.8-X instead of 0.1.9-X. libtirpc-0.1.7-20.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. |