Bug 435274 - (CVE-2008-1198) CVE-2008-1198 initscripts: IPSec ifup script allows for aggressive IKE mode
CVE-2008-1198 initscripts: IPSec ifup script allows for aggressive IKE mode
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: initscripts Maintenance Team
Brock Organ
http://www.netsc.ch/IMG/pdf/Targeting...
impact=low,public=20080228,reported=2...
: Security
Depends On: 768962
Blocks: 742493
  Show dependency treegraph
 
Reported: 2008-02-28 09:17 EST by Aleksander Adamowski
Modified: 2012-02-21 03:18 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-21 03:17:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksander Adamowski 2008-02-28 09:17:38 EST
Description of problem:

The default IPSec ifup script (/etc/sysconfig/network-scripts/ifup-ipsec)
initializes the racoon configuration to use aggressive IKE mode, then fallback
to main IKE mode if that fails:

...
remote $DST
{
  exchange_mode aggressive, main;
...

Due to widely known attacks, the aggressive mode should be only used when public
key authentication is in use. In practice, most administrators use IPSec with
PSK authentication, which combined with aggressive mode leads to aforementioned
vulnerability.

See this whitepaper for more information:
http://www.netsc.ch/IMG/pdf/TargetingIKE_en.pdf

The exchange_mode should be changed to "main" only or, for a low-security
fallback, to "main, aggressive" (in the opposite order than currently).
Comment 1 Josh Bressers 2008-02-28 11:19:30 EST
Hi Aleksander,

Can you elaborate on this paper?  I'm having a bit of a rough time understanding
exactly what the problem is here.  My understanding from reading the paper is
that  the attack described could allow a remote attacker to determine
information about the VPN gateway.

I don't think I'm understanding the problem properly, can you help explain this
in a manner I can grasp?

Thanks.
Comment 2 Aleksander Adamowski 2008-02-29 07:03:15 EST
Sorry, the paper I've linked to may not be as readable as the original paper by
Michael Thumann and Enno Rey which you can read over here:

http://www.ernw.de/download/pskattack.pdf

In short, the PSK hash in Aggressive mode is sent unencrypted over the network,
and this condition greatly eases cracking (brute force/dictionary) attacks on
the PSK.

Quoting the Thumann/Rey paper:

"In IKE Aggressive mode the authentication hash based on a preshared key (PSK) is
transmitted as response to the initial packet of a vpn client that wants to
establish an
IPSec Tunnel (Hash_R). This hash is not encrypted. It's possible to capture these
packets using a sniffer, for example tcpdump and start dictionary or brute force
attack
against this hash to recover the PSK. With IKECrack
(http://ikecrack.sourceforge.net)
is a tool available to do this job.
This attack only works in IKE aggressive mode because in IKE Main Mode the hash
is already encrypted. Based on this facts IKE aggressive mode is not very secure."


That's the theory, in practice you can try the attack yourself using IKECrack.


Apart from security problems, this default configuration also causes
interoperability problems (which in fact have led me to this investigation).

When you try to setup an IPSec transport mode association between Red Hat
(tested on RHEL4) and Windows XP, the associations cannot be successfully
initiated from the Red Hat side.

When Windows initiates the association, it's set up properly.

When analyzing network traffic dump one can clearly see that Red Hat offers key
exchange using ISAKMP Aggressive mode. Windows simply ignores this request and
negotiation eventually times out on Red Hat side.

This is both combination of improper behaviour on Windows side (it rightfully
doesn't accept the Aggressive mode because it's insecure, but it should reply
indicating that the proposed mode of key exchange isn't acceptable - instead it
remains silent) and on Red Hat side (it should offer the more secure "main" mode
first).
Comment 4 Steve Conklin 2008-02-29 12:30:11 EST
I concur with the reporter. Agressive mode has vulnerabilities and should not be
the default. This shouldn't impact any administrators, (at least not in
homogeneous Red Hat networks) and if it does, they will be the ones who are
knowledgable enough to set up their own configurations anyway.

It's possible that this will cause other interoperability problems with other
vendors, but I have no way of predicting what those may be. I think the risk is low.
Comment 5 Josh Bressers 2008-03-06 13:58:03 EST
Given that this flaw is the result of a bad configuration option, I'm going to
request a CVE id for this issue and we shall see about getting it fixed in a
future security update.
Comment 6 Josh Bressers 2008-03-06 14:09:10 EST
Steve,

Does this only affect Red Hat Enterprise Linux 5, or are others affected as well?
Comment 7 Bill Nottingham 2008-03-06 14:13:08 EST
It's the same in 3 and 4.
Comment 8 Josh Bressers 2008-03-06 15:02:58 EST
I'm moving this bug to the Security Response product for proper tracking as a
security issue.
Comment 11 Vincent Danen 2012-01-26 11:10:30 EST
Acknowledgements:

Red Hat would like to thank Aleksander Adamowski for reporting this issue.
Comment 12 errata-xmlrpc 2012-02-20 22:01:50 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2012:0312 https://rhn.redhat.com/errata/RHSA-2012-0312.html

Note You need to log in before you can comment on or make changes to this bug.