Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Apr 2022 18:15:46 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 263226] carp does not include carp_advskew or carp_advbase in HMAC
Message-ID:  <bug-263226-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263226

            Bug ID: 263226
           Summary: carp does not include carp_advskew or carp_advbase in
                    HMAC
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: emaste@freebsd.org

Issue reported on the fulldisclosure list in 2010
https://seclists.org/fulldisclosure/2010/Dec/489

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.

This behaviour can be exploited to force a backup member to assume the role
of master by capturing a master CARP advertisement, updating the two fields
in question to 255 and replaying the modified packet. A backup node will
receive this packet and the hash check will be satisfied as the two modified
fields are not included in the hash generation. A backup node will now
assume the master role and the current master will step down to backup.

At this point, the attacker can now capture an advertisement from the new
master. By replaying both of the unmodified master advertisements, all CARP
nodes assume the backup role. At this point, a Denial of Service (DoS)
condition has been introduced as no device answers ARP requests for the
Virtual IP (VIP). The attacker can now decide whether to start answering ARP
for the VIP therefore performing a Man in the Middle (MitM) attack.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263226-227>