Vulnerability Development mailing list archives

Perl 5.6.0 (on Linux) getpwuid() leave /etc/shadow opened


From: Arkadi Shishlov <arkadi () it lv>
Date: Tue, 30 Jul 2002 00:44:17 +0300

  I'm not sure how serious this issue is, but I think it may cause
  problems in some environments.

  The system is Linux, RedHat 7.0, Perl 5.6.0, glibc 2.2.4, latest
  updates.

  Recently I run 'lsof' on unprivileged Apache httpd process running
  mod_perl application and was pretty surprised to see /etc/shadow in
  the list of opened files. I've traced this to CGI.pm, which use
  getpwuid()[7]/tmp to find temporary directory. CGI.pm was preloaded
  by master httpd process with root privileges.

  I've tried some perl one-liners and found that there is a problem
  with getpwuid() Perl (not glibc) function:

ida(/0)root:~> perl -e 'getpwuid($<); sleep 100' &
[1] 27102
ida(/0)root:~> lsof -p 27102|grep shadow
perl    27102 root    3r   REG   80,2    1262 289062 /etc/shadow
ida(/0)root:~> [1]+  Done                    perl -e 'getpwuid($<); sleep 100'

  So any (Perl, libperl.a) program, that is originally started with
  superuser privileges, calls getpwuid(), then drops privileges still
  have read-only access to /etc/shadow file. Fortunately,
  close-on-exec flag is set and only fork()'ed children can use file
  descriptor.

  One real example of such application is Apache with mod_perl with
  CGI.pm preloaded. Of course, starting Apache+mod_perl by root (even
  preloading standard modules only) means quite high level of trust.
  It is probably organization internal server, or customer dedicated
  server (in hosting environment), but there is no good reason to have
  go+r on /etc/shadow anyway.

  I also examined Perl 5.6.1 on Linux and 5.00503 on FreeBSD and found
  that these versions close shadow password database after use.


arkadi.


Current thread: