[Openswan dev] Re: openswan potential DoS in sarge

[Paul Wouters]

On Sun, 16 Apr 2006, Rene Mayrhofer wrote:

> [Since I'm CC'ing the list, this is about the pluto crash fixed with 2.4.0,
> see http://lists.openswan.org/pipermail/dev/2005-April/000844.html for the
> problem description.]

For the record, the crasher meantioned here is the one causing: ASSERTION FAILED at
crypto.c:219: st->st_new_iv_len >= e->enc_blocksize

> seem to suggest this. So it seems to be secure in the sense that only
> authorized users can crash it. However, this is typically also seen as a DoS
> (comparable to local privilege escalation bugs).

Yes. This one, and the ones frim the IPsec Proto testsuite (that caused us to
release openswan 2.4.3 and 2.4.4) can only crash pluto in phase2, so some form
of authentiction has already taken place.

> > Do I understand it correctly, that the crash can't be reproduced with road-
> > warriors from stable?
> Correct. pluto from testing/unstable triggers it reproducably, but, pluto from
> stable does not.

What version is of openswan is in debian stable?

> > At a first glance this doesn't smell like a security problem (but that
> > depends on the answers above). Intercompatibility between older and newer
> > versions is certainly desirable, but OTOH roadwarriors are under control of
> > the local admin as well and can be forced to run stable on their notebooks
> > as well.
> True, but assuming an adversary, it can be a DoS for large gateways with many
> roadwarriors. The logs should reveal the culprit, but it's still denial of
> service.

There are more bugs that should be applied to openswan-2.4.0. For instance the
documented ones from the IPsec Proto testsuite that were released a while ago
that caused the release of openswan 2.4.3 and 2.4.4.

> > Upgrading to 2.4.5 isn't an option in either case, it has the potential to
> > introduce more regressions and incompatibilities for existing setups, that
> > it would fix in this specific use case.

Openswan 2.4 is considered the "stable" tree. If you still think you want to
cherry pick from those fixes, please look at the cvs mailinglist archive at
http://lists.openswan.org/pipermail/cvs/ and see which commits you should apply.

A quick browse tells me:
http://lists.openswan.org/pipermail/cvs/2005-November/005580.html
http://lists.openswan.org/pipermail/cvs/2005-November/005557.html
http://lists.openswan.org/pipermail/cvs/2005-November/005594.html
http://lists.openswan.org/pipermail/cvs/2005-November/005593.html

Please check with the latest code as i believe one of these might have been
un-done.

> > I'd recommend to contact upstream and ask them if they can isolate a patch,
> > which fixes the crash. If it's isolated and easily reviewable it may be a
> > candidate for important bug fixes entering a Sarge stable update.
> Paul, Michael, what do you think? Is the fix to it trivial to backport? I
> would feel safer with Debian stable having a pluto daemon that can't be
> crashed remotely.

I would cherry pick the non-klips, non-testing, non-new-feature patches from
openswan-2.4.x and try to get that in debian. The specific fixes for the crashers
are all pretty straightforward to backport though.

Paul