New bug affecting at least one ipsec product offered by Gentoo
Steps to Reproduce:
openswan-1.x is not vulnerable.
openswan-2.4.1 and earlier are.
I am testing an openswan-2.4.2 ebuild and will upload shortly.
strongswan is not vulnerable.
ok, openswan-2.4.2 is in portage. need to get 2.4.2 stable on amd64 (i have
hardware) then i will remove 2.2.0 and mark 2.4.2 stable on x86 and amd64.
anyone on the amd64 team want to test as well?
all revisions of openswan are ~ppc so leaving that way. however, getting ppc
team member to test would be great as my ppc hardware is no longer running linux.
ok, just for those who may test, i am working on an openswan-2.4.3 ebuild as
there was an assert found when using a PSK+ID in aggressive mode. Just got the
info from kenb with xelerence and downloaded the new tarball. i'll put a note
here when it is in portage.
openswan-2.4.3 is in portage.
Arches please test and mark stable.
Is there is reason the KLIPS engine cannot be selected for 2.6?
(IMHO) The KLIPS engine has some advantages when builing netfilter rules.
Hopefully I'm not alone here, but could someone tell me how I can test this on
x86 to make sure it is not broken? Upstream's wiki appears to be down.
Mark - i have already tested some on x86, but there are a number of scenarios.
You can look here: http://gentoo-wiki.com/HOWTO_OpenSwan_2.6_kernel for some info.
If you need further help, just find me on IRC.
*sigh*... openswan-2.4.4 is on it's way (as per kenb from xelerance). it has
more ddos fixes. i will post an update once it is released and i test/commit it
Back to upstream waiting for 2.4.4
2005-11-18 : Xelerance has released Openswan 2.4.4 that fixes the secound
vulnerability found by the NISCC Advisory 3756/NISCC/ISAKMP.
See http://www.openswan.org/niscc2/ and bump.
2.4.4 is now in portage. Unless we get a huge bug report, I plan on marking this
stable on x86/amd64 and getting rid of 2.2.0 in 24 hours.
maintainer / x86 / amd64 teams: please mark 2.4.4 stable (if stable :) )
openswan-2.4.4 is now marked stable on x86 and amd64.
Ready for GLSA vote. I tend to vote yes, due to the original issue (3DES crafted
packet with invalid keylength) rather than the additional lame ones (DoS if PSK
known and aggressive mode enabled, already vulnerable to MiM anyway)...
I tend to say yes, too
Yes please issue a GLSA
k, this is ready for GLSA then.