bugtraq - Re: OpenBSD CARP Hash Vulnerability

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <AANLkTimh4rBXBy9tEgXkA+QHiw_=smb6hkxyR_ghRXkE@mail.gmail.com>
Date: Mon, 20 Dec 2010 13:14:51 -0500
From: Jeffrey Walton <noloader@...il.com>
To: Sam Banks <wolfie@...ogeny.ac.nz>
Cc: bugtraq@...urityfocus.com
Subject: Re: OpenBSD CARP Hash Vulnerability

On Fri, Dec 17, 2010 at 10:08 PM, Sam Banks <wolfie@...ogeny.ac.nz> wrote:
> Hello Bugtraq,
>
> I disclosed this bug to the BSDs and no one is interested in fixing it
> so here you go. The two files attached are as follows:
>
> [SNIP]
>
> The OpenBSD CARP implementation (and all derivatives, such as FreeBSD
> and NetBSD) fails to include all fields contained in the "carp_header"
> structure[1] when calculating the SHA1 HMAC hash of the packet in the
> function carp_proto_input_c[2]. The two 8-bit fields not included in
> the hash generation are "carp_advskew" and "carp_advbase". Among other
> functions, the fields are both set to 255 by the master CARP node to
> indicate that it wants to step down from the master role.
"Analysis of the SSL 3.0 Protocol" by Schneier and Wagner comes to mind.

3.6 The Horton principle

Let’s recall the ultimate goal of message authentication. SSL provides
message integrity protection just when the data passed up from the
receiver’s SSL record layer to the protected application exactly
matches the data uttered by the sender’s protected application to the
sender’s SSL record layer. This means, approximately, that it is not
enough to ap- ply a secure MAC to just application data as it is
transmitted over the wire—one must also authenti- cate any context
that the SSL mechanism depends upon to interpret inbound network data.
For lack of a better name, let’s call this “the Horton principle”
(with apologies to Dr. Seuss) of semantic authentication: roughly
speaking we want SSL to
    “authenticate what was meant, not what was said.”
To phrase it another way,
    Eschew unauthenticated security-critical context.

This design principle is hardly original; Abadi and Needham [AN96]
gave a version of it in the context of building secure protocols. The
Horton principle is essentially a restatement of their Principle 1 in
terms of requirements for record-layer message authentication.

[SNIP]