From ${URL} : It was reported [1],[2] that rpc.gssd in nfs-utils is vulnerable to DNS spoofing due to it depending on PTR resolution for GSSAPI authentication. Because of this, if a user where able to poison DNS to a victim's computer, they would be able to trick rpc.gssd into talking to another server (perhaps with less security) than the intended server (with stricter security). If the victim has write access to the second (less secure) server, and the attacker has read access (when they normally might not on the secure server), the victim could write files to that server, which the attacker could obtain (when normally they would not be able to). To the victim this is transparent because the victim's computer asks the KDC for a ticket to the second server due to reverse DNS resolution; in this case Krb5 authentication does not fail because the victim is talking to the "correct" server. A patch that prevents this issue has been posted [3]. To workaround this issue, set the IP/host pair in /etc/hosts so that it cannot be spoofed. A good explanation is also available here [4]. [1] http://marc.info/?l=linux-nfs&m=136491998607561&w=2 [2] http://marc.info/?l=linux-nfs&m=136500502805121&w=2 [3] http://marc.info/?l=linux-nfs&m=136493115612397&w=2 [4] http://ssimo.org/blog/id_015.html
Upstream patch available at: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=f9f5450f8f946ffc664397c86d05d27ba0406e21
net-fs/nfs-utils-1.3.0 is released upstream Needs newer sys-apps/keyutils will not build against 1.5.5 but unstable 1.5.9 works
stable version includes this fix now
(In reply to SpanKY from comment #3) > stable version includes this fix now I do not see 1.28 as stable, was it a typo and you meant 1.29 which is stable?
(In reply to Yury German from comment #4) no, both modifications were accurate
As per vapier this was fixed in 1.28 Maintainer(s), please drop the vulnerable version(s). New GLSA Request filed.
Ping for cleanup
(In reply to Kristian Fiskerstrand from comment #7) > Ping for cleanup Double ping. Will wait a few days for timeout.
Thank you for cleanup.
This issue was resolved and addressed in GLSA 201412-02 at http://security.gentoo.org/glsa/glsa-201412-02.xml by GLSA coordinator Kristian Fiskerstrand (K_F).
