** DISPUTED ** firehol in firehol 1.256 allows local users to
overwrite arbitrary files via a symlink attack on (1)
/tmp/.firehol-tmp-#####-*-* and (2) /tmp/firehol.conf temporary
files. NOTE: the vendor disputes this vulnerability, stating that an
attack "would require an attacker to create 1073741824*PID-RANGE
I did not test 1.273, because it wont let me ebuild ... unpack it (EAPI issues), but the other versions are vuln.
There won't be a vendor-supplied fix and the package has no maintainer. Shall we remove it?!
Kerin and Gordon seem to have some interest in the program, and considering this has an almost zero attack vector, I would no go for removal.
I'll attach a patch, can someone else please review, and are you guys able to test this? Thanks.
Created attachment 177606 [details, diff]
I'm unable to test as I don't use it. I just bumped it @ Kerin's request because he provided the bump, I trust his work is always quality and he's a great help/contributor.
The patch looks good.
Read to vote, I vote NO.
Let's get this tested, committed and stable first :-)
I thought that we could do parallel voting and testing/commiting/stabling, I should have changed to [ebuild/glsa?] though.
Kerin.. have any interest in testing this patch?
Re: Comment 2 - Thanks for your consideration and for the patch.
Re: Comment 8 - Yes, especially as I have recently re-instated my Linux-based gateway after a protracted hiatus caused by a change of ISP and hardware-related matters. As such, I have just applied the patch to a newer version which I am currently using (1.286) and it works as expected. Duly, it gets the thumbs up from these quarters!
+*firehol-1.273-r1 (15 Jul 2009)
+ 15 Jul 2009; Robert Buchholz <email@example.com>
+ +files/firehol-1.273-CVE-2008-4953.patch, +firehol-1.273-r1.ebuild:
+ Patch CVE-2008-4953, symlink attack on a firehol directory in /tmp. Patch
+ tested by Kerin Millar, thanks. Fixes bug 246013.
Arches, please test and mark stable:
Target keywords : "x86"
Please target amd64 also.
Kerin, the ebuild has not been stable on amd64 before. It is therefore against our (security's) policy to request stabling.
I fully agree the package should also have a stable on amd64, but it should be done in accordance with the regular time lines (i.e. 30 days after being in the tree, no open bugs). Please open a bug around August 15 to request stabling of this version on amd64. Feel free to put me in cc on that bug if there's any issue.
glsa vote: i vote NO as the $RANDOM-$RANDOM makes success of an attack highly unlikely. CVE is disputed for this reason.
Craig's NO in comment 5, my NO here. Closing.