Bug 627498 (CVE-2010-2953) - CVE-2010-2953 couchdb: start-up script sets insecure LD_LIBRARY_PATH
Summary: CVE-2010-2953 couchdb: start-up script sets insecure LD_LIBRARY_PATH
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2010-2953
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-26 08:13 UTC by Tomas Hoger
Modified: 2010-12-22 15:51 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-22 15:51:12 UTC
Embargoed:


Attachments (Terms of Use)

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.


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