Red Hat Bugzilla – Bug 647941
CVE-2010-4173 libsdp: insecure log file handling
Last modified: 2015-08-19 04:58:45 EDT
Leif Nixon reported that libsdp is vulnerable to insecure log file handling. libsdp is a library that is supposed to be LD_PRELOAD'd to enable an application to communicate over the Infiniband SDP protocol instead of ordinary TCP. When libsdp is dlopened, by default it will fopen a log file with a predictable name: /var/log/libsdp for root processes, and /tmp/libsdp.log.$UID for non-root processes. The root process log file is suitably protected, however the non-root processes are not. The vulnerable code is in src/log.c, which does first check that the destination is not a symlink, in which case it will refuse to open it. However, this is still vulnerable to a hardlink attack, and a race condition where a symlink can be created between the lstat() call and the fopen() call: 192 /* double check the file is not a link */ 193 status = lstat(tfilename, &lstat_res); 194 if ( (status == 0) && S_ISLNK(lstat_res.st_mode) ) { 195 __sdp_log( 9, "Cowardly refusing to log into:'%s'. " 196 "It is a link - thus is a security issue.\n", tfilename ); 197 return 0; 198 } 199 200 f = fopen( tfilename, "a" ); This vulnerability is fixed in the latest version of libsdp (libsdp-1.1.105-0.4.g1b9b996.tar.gz) available at: http://www.openfabrics.org/downloads/libsdp/ Acknowledgements: Red Hat would like to thank Leif Nixon for reporting this issue.
One solution that Leif provided is to create a directory in /tmp owned by the non-root user, and writable only to that uid, and place the log file there. Another solution is to first look to write the file in $HOME (if possible; may not be with some system accounts), and if that is not available, write to /tmp/ as noted above. Leif, has upstream responded to you as of yet, perhaps with a patch to correct the issue?
Hi Leif, Looking at log.c again, it seems you can configure libsdp to log in the users home dir as well as /tmp. I agree with the fact that logging in /tmp is insecure, but i guess the mitigating factor here could be to allow users to log in their home dir. rather.
(In reply to comment #4) > Hi Leif, > Looking at log.c again, it seems you can configure libsdp to log in the users > home dir as well as /tmp. How/where can this be configured?
In /etc/ofed/libsdp.conf, you need to add/modify: log min-level 1 destination file /home/test/libsdp.log Then try running: export LD_PRELOAD=/usr/lib/libsdp.so; /usr/local/bin/iperf -s -B <some_ip> You can see a log file created in /home/test. I guess this proves that, this isnt a vuln. but rather a mis-configuration?
The symlink check in comment 0 is still buggy and prone to a race condition. It is true that this can be worked around by changing the default log file location to $HOME, but I feel that it would be better to make the code secure even when logging to /tmp. I have been in contact with the upstream maintainer at Mellanox, and I understand they will adopt the latter approach, by creating a directory under /tmp with proper permissions, and then log into that.
(In reply to comment #7) > > I have been in contact with the upstream maintainer at Mellanox, and I > understand they will adopt the latter approach, by creating a directory under > /tmp with proper permissions, and then log into that. Any ETA on when he will release the patch/new version with the fix?
Hm, it actually looks to be already present in the latest daily; the 1.1.105 series available at http://www.openfabrics.org/downloads/libsdp/
Statement: (none)