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.
