Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140314180531.GA6692@steve.org.uk>
Date: Fri, 14 Mar 2014 18:05:31 +0000
From: Steve Kemp <steve@...ve.org.uk>
To: oss-security@...ts.openwall.com
Subject: Insecure usage of temporary files in GNU Readline


  Whilst auditing some code for insecure uses of temporary
 files I spotted a potential area of concern in GNU readline.
 (via an embedded copy of the same inside the Debian source
 of GDB.)

  The code in question comes from readline 6.x and is contained
 in util.c:


int
_rl_tropen ()
{
  char fnbuf[128];

  if (_rl_tracefp)
    fclose (_rl_tracefp);
  sprintf (fnbuf, "/var/tmp/rltrace.%ld", getpid());
  unlink(fnbuf);
  _rl_tracefp = fopen (fnbuf, "w+");
  return _rl_tracefp != 0;
}


  _rl_tropen is invoked from _rl_trace, which is a debugging aid,
 and it is implied that the function is private, because it is defined
 in rlprivate.h:

/* rlprivate.h -- functions and variables global to the readline library,
          but not intended for use by applications. */

  That said the function _is_ available for using/linking, as
 a trivial test program would demonstrate:

       http://pastebin.com/T0XimKED

   Given how widely used this library is potentially many applications are
 unknowingly vulnerable to a classic race-condition.

  I'm throwing this out there for two reasons:

    * In theory this is exploitable, and should be fixed.

    * In practice I cannot find an application which invokes _rl_trace,
      although there are tantalising clues such as this page of commits
      which refers to a snapshot of GNU Bash:

            https://gitlab.com/bminor/bash/commit/b0c16657b4514191b4f6c328615d162726758247

   Feel free to allocate an identifier, or even scan some of your
 projects that have readline dependencies ;)

   This is the first announcement of this issue I've made, I can
 imagine some more paranoid distributions might wish to update, but
 equally this seems so low-risk that I didn't consider it worthy
 of vendor-sec.

Steve
-- 
http://tweaked.io/

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.