Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

TITLE:
Pine rpdump File Creation Race Condition Vulnerability

SECUNIA ADVISORY ID:
SA14899

VERIFY ADVISORY:
http://secunia.com/advisories/14899/

CRITICAL:
Not critical

IMPACT:
Manipulation of data

WHERE:
Local system

SOFTWARE:
Pine 4.x
http://secunia.com/product/710/

DESCRIPTION:
Imran Ghory has reported a vulnerability in Pine, which potentially
can be exploited by malicious, local users to perform certain actions
on a vulnerable system with escalated privileges.

The vulnerability is caused due to a race condition in the rpdump
utility when creating files. The problem is that there is a larger
gap between the time that a check is made to determine whether a
local file exists and the time that the file is created. This can be
exploited via symlink attacks to overwrite arbitrary files with the
privileges of the user running the vulnerable program.

Successful exploitation requires write permissions to the directory,
which rpdump creates the local file in.

The vulnerability has been reported in Pine 4.62. Other versions may
also be affected.

SOLUTION:
Ensure that only the user has write permissions to the directory used
for creating the file with rpdump.

PROVIDED AND/OR DISCOVERED BY:
Imran Ghory

net-mail please advise.

Upstream hasn't provided a patch yet, I will mail Eduardo Chappa (probably most
active one there) and ask about it.

Mr. Chappa informed me that Pine team is aware of this vulnerability, and is
working on it. He also commented on the vulnerability (there was no disclaimer
with his e-mail, so I guess it's alright to reproduce):

[quote]
  I saw the report and I took a look at the source code of rpdump, so I 
will tell you what I think.

  First off all, rpdump is a program that downloads remote configuration 
information of Pine to a local file. In another words, an attacker could 
be able to see a .pinerc file that a person is downloading. The attack 
requires that a user be able to write in someone elses directory, but in 
that case you can probably overwrite a .pinerc file, so the system is 
horribly configured. In my opinion this is not a big issue.

  The only information that you could gain by symlinking a .pinerc file is 
personal information about servers, no passwords can be obtained this way 
(unless the user writes explicitly in that file the passwords). I do not 
consider this information very interesting, unless one connects insecurely 
to those servers, in whose case it may be interesting for the attacker, 
but in that case, chances are that someone else already spied that 
connection and got the sensitive information necessary to connect to that 
server.

  By looking at the source code of rpdump, I see that pine checks for 
access to the local file that is going to be used to download such remote 
information, way before it creates such file, it does it even before it 
connects to the remote server. I myself don't know how a call to "access"
will alert an attacker to create a symlink to a non existing file, I guess 
one could see it from the processes table, but I really don't see how 
useful this attack is. However, if you know of a way to do this, then 
there is enough time to do this attack (in the sense that it could take a 
couple of seconds to complete this operations, rarely it should take more 
than 10 seconds, and that's too long).
[/quote]

I tend to agree with the author this is not a serious thing, as almost all race
conditions discovered by Imran are...

CAN-2005-1066

Ok, upstream has released 4.63 (few days ago, I failed to notice), which has
this fixed (according to release notes). I've just committed an
pine-4.63.ebuild to portage.

Thx Ticho.

Arches please test and mark stable.

Downgrading severity.

Stable on x86.

Oh, and ppc-macos should fix pine in regards to mit-krb5:

 RDEPEND.badindev               8
   mail-client/pine/pine-4.61-r2.ebuild: ppc-macos(default-darwin/macos/10.3) ['app-crypt/mit-krb5']
   mail-client/pine/pine-4.62-r1.ebuild: ~ppc-macos(default-darwin/macos/10.3) ['app-crypt/mit-krb5']
   mail-client/pine/pine-4.62.ebuild: ~ppc-macos(default-darwin/macos/10.3) ['app-crypt/mit-krb5']
   mail-client/pine/pine-4.61-r4.ebuild: ppc-macos(default-darwin/macos/10.3) ['app-crypt/mit-krb5']
   mail-client/pine/pine-4.61-r3.ebuild: ppc-macos(default-darwin/macos/10.3) ['app-crypt/mit-krb5']
   mail-client/pine/pine-4.62-r2.ebuild: ~ppc-macos(default-darwin/macos/10.3) ['app-crypt/mit-krb5']
   mail-client/pine/pine-4.63.ebuild: ~ppc-macos(default-darwin/macos/10.3) ['app-crypt/mit-krb5']
   mail-client/pine/pine-4.61-r5.ebuild: ppc-macos(default-darwin/macos/10.3) ['app-crypt/mit-krb5']

Stable on ppc.

sparc stable.

Stable on alpha + ia64.

Stable on amd64.

This one is ready for GLSA vote. I tend to vote NO.

I would agree, NO glsa for this questionable issue.

Yup, this is a very minor issue. NO glsa, if you need one more vote. :)

Changing to a full NO -> closing without GLSA.