Bug 435274 (CVE-2008-1198) - CVE-2008-1198 initscripts: IPSec ifup script allows for aggressive IKE mode
Summary: CVE-2008-1198 initscripts: IPSec ifup script allows for aggressive IKE mode
Alias: CVE-2008-1198
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: initscripts Maintenance Team
QA Contact: Brock Organ
URL: http://www.netsc.ch/IMG/pdf/Targeting...
Depends On: 768962
Blocks: 742493
TreeView+ depends on / blocked
Reported: 2008-02-28 14:17 UTC by Aleksander Adamowski
Modified: 2021-02-25 17:19 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-02-21 08:17:38 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0312 0 normal SHIPPED_LIVE Low: initscripts security and bug fix update 2012-02-21 07:25:10 UTC

Description Aleksander Adamowski 2008-02-28 14:17:38 UTC
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

See this whitepaper for more information:

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 16:19:30 UTC
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?


Comment 2 Aleksander Adamowski 2008-02-29 12:03:15 UTC
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:


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
against this hash to recover the PSK. With IKECrack
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

Comment 4 Steve Conklin 2008-02-29 17:30:11 UTC
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 18:58:03 UTC
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 19:09:10 UTC

Does this only affect Red Hat Enterprise Linux 5, or are others affected as well?

Comment 7 Bill Nottingham 2008-03-06 19:13:08 UTC
It's the same in 3 and 4.

Comment 8 Josh Bressers 2008-03-06 20:02:58 UTC
I'm moving this bug to the Security Response product for proper tracking as a
security issue.

Comment 11 Vincent Danen 2012-01-26 16:10:30 UTC

Red Hat would like to thank Aleksander Adamowski for reporting this issue.

Comment 12 errata-xmlrpc 2012-02-21 03:01:50 UTC
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.