Bug 627498 (CVE-2010-2953)

Summary:	CVE-2010-2953 couchdb: start-up script sets insecure LD_LIBRARY_PATH
Product:	[Other] Security Response	Reporter:	Tomas Hoger <thoger>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	lemenkov
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:	2010-12-22 15:51:12 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:

Description Tomas Hoger 2010-08-26 08:13:00 UTC

Dan Rosenberg reports:

  http://thread.gmane.org/gmane.comp.security.oss.general/3358

  I discovered that the /usr/bin/couchdb script on Debian/Ubuntu sets an
  insecure LD_LIBRARY_PATH environment variable, such that libraries
  from the current directory are loaded.  If a local attacker placed a
  maliciously crafted shared library in a directory and an administrator
  were tricked into launching CouchDB from this directory, arbitrary
  code execution could be achieved.  This vulnerability is only
  triggered when the /usr/bin/couchdb script is executed explicitly,
  since the init script (/etc/init.d/couchdb) changes the current
  directory before launching CouchDB.

  The vulnerability was introduced by Debian patch
  "mozjs1.9_ldlibpath.patch" on 3/24/2009.

While Fedora / EPEL packages don't seem to include mentioned Debian patch, they include different LD_LIBRARY_PATH-setting change that seems to be inspired by Debian icu-config.patch patch:

http://pkgs.fedoraproject.org/gitweb/?p=couchdb.git;a=blob;f=couchdb.spec;h=aaef7be9;hb=f13/master#l81

If LD_LIBRARY_PATH is unset before running /usr/bin/couchdb, it gets set to /usr/lib{,64}: , which causes linker to search for libs relative to the current working directory, possibly allowing arbitrary code execution if run from some attacker-controlled/writeable directory (such as /tmp).   I don't know what typical couchdb use case is, it may be rather unlikely to have couchdb run from arbitrary directories.

I wonder why we need to change LD_LIBRARY_PATH at all.  Only /usr/lib or /usr/lib64 is added there, so setting it should be redundant as those directories are in linker search path by default.  If setting it is really required, something like this should work instead:
  LD_LIBRARY_PATH=%{_libdir}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}

Comment 1 Peter Lemenkov 2010-08-26 08:37:20 UTC

Thanks! I will provide fix very soon.

(In reply to comment #0)

> attacker-controlled/writeable directory (such as /tmp).   I don't know what
> typical couchdb use case is, it may be rather unlikely to have couchdb run from
> arbitrary directories.

Unfortunately running CouchDB from arbitrary directory is one of possible (and rather popular) user-cases. So yes, this needs to be fixed urgently.

> I wonder why we need to change LD_LIBRARY_PATH at all.  Only /usr/lib or
> /usr/lib64 is added there, so setting it should be redundant as those
> directories are in linker search path by default.  If setting it is really
> required, something like this should work instead:
>   LD_LIBRARY_PATH=%{_libdir}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}

It seems that this line isn't necessary at all, so I will simply remove it.

Comment 2 Tomas Hoger 2010-12-22 15:51:12 UTC

Fixed in F13 and EPEL-5.