Guillem Jover pointed out:
a deficiency in the way rpcbind gathered / saved registrations from / to
dumped file(s). A local attacker could use this flaw to conduct symbolic
link attacks, leading to un-authorized disclosure of sensitive information
and / or to important system files data integrity corruption.
This issue affects the versions of the rpcbind package, as shipped
with Fedora release of 11, 12, and 13.
So what is the answer here... do we need to add some type encryption
or simply change where the file lives...
The name CVE-2010-2061 has been assigned for the "any user can craft those two files before the daemon has started for the first time, which the daemon will parse".
The name CVE-2010-2064 has been assigned to the "symlinks are followed on creation of those files".
As noted: http://www.openwall.com/lists/oss-security/2010/06/08/3
(In reply to comment #1)
> This issue affects the versions of the rpcbind package, as shipped
> with Fedora release of 11, 12, and 13.
This issue did not affect those Fedora versions, it's quite possible Fedora was never affected, or was only affected for a short time long ago. Looking at the Fedora rpcbind.spec, it contains:
[ ... ]
This changes location of those two files form default /tmp to safe /var/lib/rpcbind (directory is not group writeable). I checked (strings on rpcbind) current and older (from F-8) builds and they use files form /var/lib/rpcbind.
Here is the patch that added support for specifying state dir location via configure, and it also add --with-statedir to .spec file: