Bug 647941 (CVE-2010-4173)
| Summary: | CVE-2010-4173 libsdp: insecure log file handling | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED WONTFIX | QA Contact: | Infiniband QE <infiniband-qe> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | bressers, dledford, honli, jrusnack, nixon, security-response-team |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-03-02 19:24:13 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: | |||
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) |
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.