Bug 914171 (CVE-1999-0195) - VUL-0: CVE-1999-0195: rpcbind/portmap: spoofing of localhost possible
Summary: VUL-0: CVE-1999-0195: rpcbind/portmap: spoofing of localhost possible
Status: RESOLVED FIXED
Alias: CVE-1999-0195
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-21 20:29 UTC by Marcus Meissner
Modified: 2015-01-22 14:31 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2015-01-21 20:29:09 UTC
http://www.iss.net/security_center/reference/vuln/RPC_Portmap_Set_Spoof.htm

http://archives.neohapsis.com/archives/bugtraq/1999_1/0403.html

-----BEGIN PGP SIGNED MESSAGE-----


*** RPCBIND SECURITY ADVISORY ***

Discovered by: Martin Rosa, mrosapgci.ca
Authored by: Patrick Gilbert, gilbertpgci.ca

The vulnerable versions of rpcbind are contained in:

- -Linux 2.0.34
- -Irix 6.2
- -Wietse's rpcbind 2.1 replacement (Wietse's warns
 the use of proper filtering to be used with his package, but did you
 really read the README?)
- -Solaris 2.6 (you can add and delete services that were inserted remotely)
- -Other version have yet to be tested.

The problem:

Rpcbind permits a remote attacker to insert and delete
entries without superuser status by spoofing a source address.
Ironically, it inserts the entries as being owned by superuser (wietse's
rpcbind in this case).

Consequences are terrible, to say the least. Tests were conducted
with the pmap_tools available at the end of this advisory.

The solution:

Make sure you filter 127.0.0.1 and localnets at
your border router. Bad router hygiene will lead to problems.

The tools:

A source of pmap_tools for linux, as well as technical details concerning
this advisory can be obtained here:

http://www.pgci.ca/emain.html

Cheers,

- --
Patrick Gilbert				            +1 (514) 865-9178
CEO, PGCI                                          http://www.pgci.ca
Montreal (QC), Canada CE AB B2 18 E0 FE C4 33  0D 9A AC 18 30 1F D9 1A
Comment 1 Marcus Meissner 2015-01-21 20:48:37 UTC
I do not think that external interface can pretend to be 127.0.0.1 or ::1
Comment 2 Marcus Meissner 2015-01-21 21:01:54 UTC
(given the age I am hoping this does not affect us ;)
Comment 3 Swamp Workflow Management 2015-01-21 23:00:35 UTC
bugbot adjusting priority
Comment 4 Michal Marek 2015-01-22 13:56:57 UTC
The ipv4 case should be covered by the rp_filter (default 1).
Comment 5 Marcus Meissner 2015-01-22 14:10:13 UTC
from our kernel team:

Since at least the beginning of git (2.6.12), until d0daebc3d (ipv4: Add interface option to enable routing of 127.0.0.0/8) such packets were discarded by ip_route_input_slow():

       if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr) ||
           ipv4_is_loopback(saddr))
                goto martian_source;

since d0daebc3d (around 3.5), this can be controlled with sysctl. The defaults
are sane.

(/proc/sys/net/ipv4/conf/*/route_localnet are all 0)
Comment 6 Marcus Meissner 2015-01-22 14:16:52 UTC
2.4.21 (SLES 8) and 2.6.5 (SLES 9) have
        if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr))
                goto martian_source;
Comment 7 Marcus Meissner 2015-01-22 14:17:06 UTC
and
        if (BADCLASS(daddr) || ZERONET(daddr) || LOOPBACK(daddr))
                goto martian_destination;
Comment 8 Marcus Meissner 2015-01-22 14:19:13 UTC
perl bin/addnote CVE-1999-0195 "The localnet address 127.0.0.1 is filtered out by default in Linux since at least 2.4.0, so spoofing this address from remote interfaces is not possible in SUSE Linux Enterprise Server 8 or newer.
Comment 9 Marcus Meissner 2015-01-22 14:20:03 UTC
hope that makes the customer happy. thanks!
Comment 10 Olaf Kirch 2015-01-22 14:21:30 UTC
Wow, who let this zombie out of its coffin? :-)

I am pretty such that this issue has been discussed to death more than 15 years ago, and that the consensus back then was that the kernel's regular filtering of martians and other bogons would prevent such attacks. Remember that rpcbind isn't the only UDP based service that uses source IP validation.

If, surprisingly, today's default configuration in SLE would allow such packets to pass, this would be a severe regression.

It would probably make sense to have an automated test case that tries to send such spoof packets and verify that they're ineffective, and run it on a regular basis.
Comment 11 Marcus Meissner 2015-01-22 14:31:00 UTC
The CVE showed up in a security scanner at a customer.

(my occams razor says that the scanner just sees "oh, portmap is open! report this CVE")