multiple vendor - PF NULL pointer dereference

[rembrandt <rembrandt@xxxxxxxxxx>]

The new advisory can get found at:

www.helith.net/txt/multiple_vendor-PF_null_pointer_dereference.txt

@Securityfocus: Your informations are wrong, a update of your DB would be fine
@Other security websites: Please modify the URL in your DB in case you do keep
                          links!

I kept all references so a update of the information should be easy.

-- ADV --

                     _   _ _____ _     ___ _____ _   _
                   / / / / ____/ /   /  _/_  __/ / / /
                  / /_/ / __/ / /    / /  / / / /_/ /
                 / __  / /___/ /____/ /  / / / __  /
                /_/ /_/_____/_____/___/ /_/ /_/ /_/
                           Helith - 0815
--------------------------------------------------------------------------------

Author           : Rembrandt
Date             : 2009-04-30
Found            : 2009-04-09
Affected Software: PF (OpenBSD Packet Filter)
Affected OS      : OpenBSD 4.2 up to 4.5 and HEAD branch up to 2009-04-11
                   NetBSD 5.x up to RC3 and HEAD branch up to 2009-04-13
                   MirOS #10 and earlier
                   MidnightBSD 0.3-current
Not affected OS  : FreeBSD
                   NetBSD 3.x, 4.x, 5.x (patched before release)
                   DragonflyBSD
                   Debian GNU/kFreeBSD
                   MidnightBSD prior 0.3
                   
                   Older versions of OpenBSD PF and products based
                   thereon might be affected as well.
                   The Bug was introduced between the OpenBSD 4.1 and 4.2
                   release.

Type             : Denial of Service

OSVDB            : 53608
Milw0rm          : 8406
CVE              : 
ISS X-Force:     : 
BID              : 34482
Secunia          : 34676 
VUPEN ID         : ADV-2009-1015

This advisory supercedes the original advisory which was just related to
OpenBSD because we had to publish an announcement in response to OpenBSD's
reaction.

Trying to fix it responsibly and get in contact with the vendor:

-- OpenBSD --
Contacted                                               2009-04-09 16:35 UTC
Patch available                                         2009-04-11 23:43 UTC

We received no response nor a notification about an upcoming patch.
Also we had no chance to coordinate or inform other projects before OpenBSD
issued the patch and a statement.

We like to mention that the issued patch is just a workaround and does not
patch or remove the affected code.

-- NetBSD --
Contacted and asked for confirmation                    2009-04-15 06:00 UTC
Were informed about further investigations              2009-04-15 9:42  UTC
Received information about upcoming Patches             2009-04-15 11:57 UTC
Received confirmation for 5.x up to RC3 and HEAD        2009-04-15 12:17 UTC

We thank the NetBSD team that they patched the PF bug prior the 5.x release!

-- FreeBSD --
Contacted and asked for confirmation                    2009-04-15 06:56 UTC
Were informed about further investigations              2009-04-15 7:56 UTC
Were informed about not being vulnerable                2009-04-15 22:05 UTC

-- DragonflyBSD --
Contacted and asked for confirmation                    2009-04-15 06:10 UTC
Were informed about not being vulnerable                2009-04-15 21:35 UTC

-- MirOS (MirBSD) --
Contacted and asked for official confirmation           2009-04-15 06:36 UTC
Received confirmation for MirBSD 10 and prior           2009-04-15 17:57 UTC

-- MidnightBSD --
Contacted and asked for official confirmation           2009-04-15 20:17 UTC
Received confirmation for MidnightBSD                   2009-04-15 22:37 UTC

-- Debian GNU/kFreeBSD --
Contacted and asked for official confirmation           2009-04-15 22:41 UTC
Were informed about not being vulnerable                2009-04-15 23:35 UTC
-- END --


OpenBSDs PF firewall is prone to a remote Denial of Service due to a NULL-
pointer dereference when handling special crafted IP datagrams. If the
firewall handles such a packet the kernel panics.
An example for such a packet would be a IPv4 packet with a ICMPv6 payload.

This affects multiple vendors because PF was incorporated into serveral OS.

The problem stems from the unification of the rule processing in pf_test_rule().
With this unification  ICMPv6 logic was applied to IPv4 packets and vice versa.
Because the handling logic asserts that the common code in pf_test has verified
that the packet contains a full ICMP header and has pulled up the mbuf up to
that point. This assertion fails when the wrong AF-version is used by pf_test
and thus pf_test_rule tries to access not allocated memory.
The affected function is in pf_change_a6 and the patch is just a workaround
because it filters the packet in pf_test() except of fixing the affected source
code.


Steps to reproduce:

If you have an affected OS in your network which does NAT or redirecting traffic
you should be able to test your IPv4 device with this simple hping command:

hping -0 -H 58 $a_host


Patches are provided for:

OpenBSD 4.3 - 4.5 (not for 4.2), HEAD after 2009-04-11
NetBSD  4.x (patched for consistency) - 5.0RC3, HEAD after 2009-04-13
MirBSD 10
MidnightBSD 0.3-current


Workaround:

The OpenBSD developers provide hints for a workaround at their errata
website too.


We like to thank the security teams of the following projects for
their friendly cooperation:

DragonflyBSD
NetBSD
FreeBSD
MidnightBSD 
MirBSD

Special thanks goes to Andreas Bogk who assisted in the assembly analysis and
Adrian Portelli of the NetBSD project for his time and permanent suggestions.


Kind regards,
Rembrandt