Bug 647941 (CVE-2010-4173) - CVE-2010-4173 libsdp: insecure log file handling
Summary: CVE-2010-4173 libsdp: insecure log file handling
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2010-4173
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact: Infiniband QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-29 21:48 UTC by Vincent Danen
Modified: 2023-05-11 15:27 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-02 19:24:13 UTC
Embargoed:


Attachments (Terms of Use)

Description Vincent Danen 2010-10-29 21:48:35 UTC
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.

Comment 1 Vincent Danen 2010-10-29 21:56:07 UTC
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?

Comment 4 Huzaifa S. Sidhpurwala 2010-11-12 07:28:08 UTC
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.

Comment 5 Vincent Danen 2010-11-12 18:27:43 UTC
(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?

Comment 6 Huzaifa S. Sidhpurwala 2010-11-15 06:39:49 UTC
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?

Comment 7 Leif Nixon 2010-11-15 08:02:46 UTC
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.

Comment 8 Huzaifa S. Sidhpurwala 2010-11-15 08:07:10 UTC
(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?

Comment 9 Leif Nixon 2010-11-15 10:03:39 UTC
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/

Comment 12 Huzaifa S. Sidhpurwala 2010-11-17 03:36:59 UTC
Statement:

(none)


Note You need to log in before you can comment on or make changes to this bug.