[1144] in linux-security and linux-alert archive
[linux-security] Pine security problem
daemon@ATHENA.MIT.EDU (Liam O. Forbes)
Wed Sep 11 18:26:02 1996
Date: Tue, 10 Sep 1996 17:26:06 -0800 (ADT)
From: "Liam O. Forbes" <lforbes@arsc.edu>
To: pine@cac.washington.edu
cc: linux-security@tarsier.cv.nrao.edu, BUGTRAQ@NETSPACE.ORG
-----BEGIN PGP SIGNED MESSAGE-----
This is in regards to the "fix" of the possible security problem in
Pine < v3.95. Pine 3.95 does indeed check for symbolic links, now, before
creating a mail lock file. However it has the same problem in another part
of the program. I have verified the problem in Pine 3.95 & Pine 3.91 using
Irix 5.3. I'll be looking into it on my Linux home system, but it's probably
there too.
While upgrading to the Pine 3.95, it was discovered that the alternate editor
feature creates a file "/tmp/pico.pid" where pid is the id of the active Pine
session.
If you use the alternate editor feature, and a symbolic link exists with the
desired name, the link isn't checked like the mail lock file is, and the editor
dumps everything into the file pointed to by the symbolic link. This can lead
to several possible security breaches via:
1. the ability to mangle a target file.
2. the ability to eavesdrop on composed messages.
3. (if you are really fancy) the ability to set up at least one bogus
.rhosts entry by sending email to someone who responds to email by
quoting entire files.
There are probably several other things that can be done via this /tmp file
problem (and have been).
To see the exact problem:
1. set the editor variable in ~/.pinerc to something like /bin/vi.
2. start up pine
3. do a long listing of /tmp
4. start composing a message in pine, switch to the alternate editor via
^_
5. do another long listing of /tmp
6. That "pico.###" file is the problem. As long as you are running the
current pine session, anyone can create a link with that name and,
at the least, capture whatever you write into your mail message.
Finally, when you exit the alternate editor, it deletes the /tmp file If
it was a link, the link gets deleted. No evidence of tampering remains.
What about using random file names and checking if those exist? The current
fix for the mail lock file seems like the work of a lazy programmer.
Liam Forbes lforbes@arsc.edu http://www.arsc.edu/~lforbes
Box 756020 910 Yukon Dr. Suite 106 Fairbanks Ak 99775-6020
907-474-1898 fax: 907-474-5494 finger: Geek code & PGP pub key
High Performance Computing Systems Programmer/Analyst I
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMjYUG3j93TwzW72NAQHiqAQAksEXmJpfPUvrZizEL9ZJ2V+XASY68rfJ
SQXYrIg9Zrhi0xi/ZpJBEk6Zzdc16d+ccdXmE6w3z0Siqq8xnN5X3N90+ENL7CeV
KHC0xfRHmDcIrs7KAbeBA9mCO0O28uY8j7fv9ELL4fxcnoS60fXL2Vmps8ii4eR6
I4PPC9IBoYw=
=Sxqi
-----END PGP SIGNATURE-----
[REW: I don't think the "random filename" idea is a good idea. It can
easily be spoofed. "checking if a file exists" is also easily
tricked. Create a link, and rename it to the expected filename and
back to something else really quick. When the target program checks
(file doesn't exist), a process switch occurs. You rename the link.
Next the program opens the link....]
