lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 15 Nov 2005 18:45:48 -0800
From: <>
To: <>
Subject: In response to ISAKMP 'vulnerabilities'

Hash: SHA1

Some thoughts on the ISAKMP advisory.

While reading over this my first thoughts are 'they wrote a fuzzer,
it exposed some vulnerabilities, interesting but not too
interesting'. I think this advisory is a tad overblown (headlined
on slashdot as 'VPN flaw allows denial of service', yes I know its
only slashdot!). There is no design flaw in ISAKMP that is being
exposed here, merely an ISAKMP fault injection suite that exposed
some implementation bugs (some of which may be exploitable, I have
no idea).

Some quotes from this advisory:


The scope was further narrowed to IKE phase 1 with pre-shared
secret authentication. Rationale behind this selection was:
 IKE phase 1 does not require any special preconditions as phase 2
does. Additionally, phase 1 aggressive mode allows sending several
payloads in the first packet.
 IKE phase 1 authentication with pre-shared secret is required from
all ISAKMP/IKE implementations.
 Potential IKE vulnerabilites in above scope can be roughly
categorised based on the on the IKE identity and shared secret:
 A. Vulnerability does not require a valid identity nor a shared
secret (greatest impact).
 B. Vulnerability requires a valid identity but not the shared
 C. Vulnerability requires both a valid identity and the
corresponding shared secret (smallest impact).

</end quote>

Test cases shown here:
indicate some vulnerabilities did not require a valid identity or
shared secret, therefore mitigation mentioned in the advisory:
"If possible, use packet filters and accept ISAKMP negotiations
only from trusted IP-addresses" is irrelevant considering ISAKMP
runs on top of UDP and spoofing an IP address is trivial. All in
all i commend this team for writing this fuzzer and exposing some
flaws in many ISAKMP implementations. Thanks for reading.
Note: This signature can be verified at
Version: Hush 2.4


Concerned about your privacy? Instantly send FREE secure email, no account required

Get the best prices on SSL certificates from Hushmail

Powered by blists - more mailing lists