The debian bug at $URL references the insecure use of temp files by fail2ban. This can be see (crudely) in our package with:
# grep 'tmpfile = ' /var/tmp/portage/net-analyzer/fail2ban-0.8.4-r2/work/fail2ban-0.8.4/config/action.d/*
/var/tmp/portage/net-analyzer/fail2ban-0.8.4-r2/work/fail2ban-0.8.4/config/action.d/dshield.conf:tmpfile = /tmp/fail2ban-dshield
/var/tmp/portage/net-analyzer/fail2ban-0.8.4-r2/work/fail2ban-0.8.4/config/action.d/mail-buffered.conf:tmpfile = /tmp/fail2ban-mail.txt
/var/tmp/portage/net-analyzer/fail2ban-0.8.4-r2/work/fail2ban-0.8.4/config/action.d/mynetwatchman.conf:tmpfile = /tmp/fail2ban-mynetwatchman
/var/tmp/portage/net-analyzer/fail2ban-0.8.4-r2/work/fail2ban-0.8.4/config/action.d/sendmail-buffered.conf:tmpfile = /tmp/fail2ban-mail.txt
This does appear fixed in the upstream repository (as mentioned in the debian bug). Roughly the same test produces the following output for the upstream SVN snapshot:
# grep 'tmpfile = ' *
dshield.conf:tmpfile = /var/run/fail2ban/tmp-dshield
mail-buffered.conf:tmpfile = /var/run/fail2ban/tmp-mail.txt
mynetwatchman.conf:tmpfile = /var/run/fail2ban/tmp-mynetwatchman
sendmail-buffered.conf:tmpfile = /var/run/fail2ban/tmp-mail.txt
The target files remain the same, however the location has changed
/var/run/* is not writable by users, so *in theory* it can't be exploited by local or remote attackers.
If there are no objections, I will create a snapshot for this one
(In reply to comment #1)
> If there are no objections, I will create a snapshot for this one
No objections here. Thank you.
fail2ban-0.8.4-r3 is now on tree with the patch from the svn repository.
(In reply to comment #3)
> fail2ban-0.8.4-r3 is now on tree with the patch from the svn repository.
Great, thank you.
Arches, please test and mark stable:
Target keywords : "amd64 hppa ppc ppc64 x86"
amd64 done. Thanks Agostino
Stable for HPPA.
x86 stable. Thanks
ppc/ppc64 stable, last arch done
GLSA Vote: Yes.
GLSA vote: Yes. GLSA request filed.
This issue was resolved and addressed in
GLSA 201406-03 at http://security.gentoo.org/glsa/glsa-201406-03.xml
by GLSA coordinator Chris Reffett (creffett).