NetBSD Security Advisory 2018-007: Several vulnerabilities in IPsec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NetBSD Security Advisory 2018-007
=
Topic: Several vulnerabilities in IPsec
Version:NetBSD-current: source prior to Tue, May 1st 2018
NetBSD 7.1 - 7.1.2: affected
NetBSD 7.0 - 7.0.2: affected
NetBSD 6.1 - 6.1.5: affected
NetBSD 6.0 - 6.0.6: affected
Severity: Remote DoS, Remote Memory Corruption
Fixed: NetBSD-current: Tue, May 1st 2018
NetBSD-7-1 branch: Thu, May 3rd 2018
NetBSD-7-0 branch: Thu, May 3rd 2018
NetBSD-7 branch:Thu, May 3rd 2018
NetBSD-6-1 branch: Thu, May 3rd 2018
NetBSD-6-0 branch: Thu, May 3rd 2018
NetBSD-6 branch:Thu, May 3rd 2018
Teeny versions released later than the fix date will contain the fix.
Please note that NetBSD releases prior to 6.0 are no longer supported.
It is recommended that all users upgrade to a supported release.
Abstract and Technical Details
==
Several bugs and vulnerabilities were discovered in the IPsec code. They
can be triggered before, or after, authentication or decryption.
Before authentication/decryption:
1) In the AH entry point, a length check was missing, and it was possible
for a remote attacker to crash the system by sending a very small AH
packet. Also, a use-after-free was present in this same entry point.
2) An inverted logic in the common IPsec entry point allowed an attacker to
remotely crash the system when both IPsec and forwarding were enabled.
3) A miscomputation in an IPsec function in charge of handling mbufs
resulted in the wrong length being stored in the mbuf header. This
allowed an attacker to panic the system when at least ESP was active.
4) A sanity check in the IPsec output path was not strong enough and
allowed an attacker to remotely panic the system when both IPsec and
IPv6 forwarding were enabled.
After authentication/decryption:
5) A use-after-free existed in the common Tunnel code. Also, a mistake in
pointer initialization allowed an IPv6 packet to bypass the "local
address spoofing" check.
6) A missing length check in the common IPsec entry point could allow an
attacker to crash the system.
7) A memory leak and a use-after-free bug could allow an attacker to
crash the system when both IPv6 and forwarding were enabled.
Solutions and Workarounds
=
For all NetBSD versions, you need to obtain fixed kernel sources,
rebuild and install the new kernel, and reboot the system.
The fixed source may be obtained from the NetBSD CVS repository.
The following instructions briefly summarize how to upgrade your
kernel. In these instructions, replace:
ARCH with your architecture (from uname -m),
KERNCONF with the name of your kernel configuration file and
VERSION with the file version below
File versions containing the fixes:
FILE HEAD netbsd-7 netbsd-7-0 netbsd-7-1
-- --
src/sys/netipsec/xform_ah.c
1.80 1.42.4.2 1.42.8.2 1.42.12.2
src/sys/netipsec/ipsec.c
1.1301.63.2.1 1.63.4.1 1.63.8.1
src/sys/netipsec/ipsec_mbuf.c
1.24 1.12.30.11.12.34.1 1.12.42.1
src/sys/netipsec/ipsec_output.c
1.75 1.40.4.1 1.40.8.1 1.40.12.1
src/sys/netipsec/xform_ipip.c
1.56 1.31.2.2 1.31.6.2 1.31.10.2
src/sys/netipsec/ipsec_input.c
1.58 1.32.4.1 1.32.8.1 1.32.12.1
src/sys/netinet6/ip6_forward.c
1.91 1.73.2.3 1.73.2.1.2.2 1.73.2.1.6.2
FILE netbsd-6 netbsd-6-0 netbsd-6-1
-- --
src/sys/netipsec/xform_ah.c
1.37.2.2 1.37.6.2 1.37.8.2
src/sys/netipsec/ipsec.c
1.55.8.1 1.55.12.1 1.55.14.1
src/sys/netipsec/ipsec_mbuf.c
1.12.10.11.12.16.1 1.12.24.1
src/sys/netipsec/ipsec_output.c
1.38.2.1 1.38.8.1 1.38.16.1
src/sys/netipsec/xform_ipip.c
1.28.8.2 1.28.14.2 1.28.22.2
src/sys/netipsec/ipsec_input.c
1.29.2.1 1.29.8.1 1.29.16.1
src/sys/netinet6/ip6_forward.c
1.69.2.2 1.69.6.2 1.69.8.2
To update from CVS, re-build, and re-install the kernel:
# cd src
# cvs update -d -P -r VERSION sys/netipsec/xform_ah.c
# cvs update -d -P -r VERSION sys/netipsec/ipsec.c
# cvs update -d -P -r VERSION sys/netipsec/ipsec_mbuf.c
# cvs update -d -P -r VERSION sys/netipsec/ipsec_output.c
# cvs update -d -P -r VERSION sys/netipsec/xform_ipip.c
Re: adding devices to puc(4)
Hi.
On 2018/05/07 16:38, John Nemeth wrote:
I'm trying to add an Oxford Semiconductor 4-port serial card
to puc(4). Using the datasheet, I've gotten to the point where
all four serial ports are probed and attached. However, I don't
seem to be able to communicate through the ports. And, there
doesn't seem to be any real documentation on puc(4). I'm trying
to figure out what the various flags mean. A URL for the datasheet
is:
https://www.semiconductorstore.com/pdf/newsite/oxford/OXPCIe954_ds.pdf
It seems that the Legacy mode (e.g. I/O mapped) of OXPCIe952 is removed
from OXPCIe954. It also seems it has no INTx support, right? Are the device's
com registers not 4 byte stride but 1 byte stride?
Here are the patches that I used to get it started:
Index: pcidevs
===
RCS file: /cvsroot/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1333
diff -u -r1.1333 pcidevs
--- pcidevs 3 May 2018 04:21:10 - 1.1333
+++ pcidevs 7 May 2018 07:58:28 -
@@ -6280,6 +6280,7 @@
product OXFORDSEMI OXPCIE952_40xc141 OXPCIe952
product OXFORDSEMI OXPCIE952_50xc144 OXPCIe952
product OXFORDSEMI OXPCIE952_60xc145 OXPCIe952
+product OXFORDSEMI OXPCIE952_7 0xc208 OXPCIe952
Not 952 but 954
/* Packet Engines products */
product PACKETENGINES GNICII 0x0911 G-NIC II Ethernet
Index: pucdata.c
===
RCS file: /cvsroot/src/sys/dev/pci/pucdata.c,v
retrieving revision 1.101
diff -u -r1.101 pucdata.c
--- pucdata.c 13 Apr 2018 07:57:04 - 1.101
+++ pucdata.c 7 May 2018 07:58:53 -
@@ -1108,6 +1108,19 @@
},
},
+ /* Oxford Semiconductor OXPCIe952 PCIe UARTs */
+ { "Oxford Semiconductor OXPCIe952 UART",
+ { PCI_VENDOR_OXFORDSEMI, PCI_PRODUCT_OXFORDSEMI_OXPCIE952_7,
+ 0, 0 },
+ { 0x, 0x, 0, 0 },
+ {
+ { PUC_PORT_TYPE_COM, PCI_BAR0, 0x1000, COM_FREQ },
+ { PUC_PORT_TYPE_COM, PCI_BAR0, 0x1200, COM_FREQ },
+ { PUC_PORT_TYPE_COM, PCI_BAR0, 0x1400, COM_FREQ },
+ { PUC_PORT_TYPE_COM, PCI_BAR0, 0x1600, COM_FREQ },
+ },
+ },
+
/* Oxford Semiconductor OXmPCI952 PCI UARTs */
{ "Oxford Semiconductor OXmPCI952 UARTs",
{ PCI_VENDOR_OXFORDSEMI, PCI_PRODUCT_OXFORDSEMI_EXSYS_EX41092,
It seems FreeBSD's puc(4) support OXPCIe954, so it will help
to see FreeBSD's sys/dev/puc/pucdata.c.
If it's a PCIe addin card, could you tell me the product name?
(I don't say I'll work to support it :))
FYI:
http://mail-index.netbsd.org/tech-kern/2014/02/09/msg016616.html
http://mail-index.netbsd.org/tech-kern/2014/01/23/msg016459.html
(If you're trying to use the device for console, you will modify
#if 0'd code in the diff.)
sys/dev/ic/com.c has a lof of #ifdefs. Some of them should not be determined
at compile time (e.g. COM16650 and COM_REGMAP), but the change is not easy.
Please someone(TM) do it.
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
adding devices to puc(4)
I'm trying to add an Oxford Semiconductor 4-port serial card
to puc(4). Using the datasheet, I've gotten to the point where
all four serial ports are probed and attached. However, I don't
seem to be able to communicate through the ports. And, there
doesn't seem to be any real documentation on puc(4). I'm trying
to figure out what the various flags mean. A URL for the datasheet
is:
https://www.semiconductorstore.com/pdf/newsite/oxford/OXPCIe954_ds.pdf
Here are the patches that I used to get it started:
Index: pcidevs
===
RCS file: /cvsroot/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1333
diff -u -r1.1333 pcidevs
--- pcidevs 3 May 2018 04:21:10 - 1.1333
+++ pcidevs 7 May 2018 07:58:28 -
@@ -6280,6 +6280,7 @@
product OXFORDSEMI OXPCIE952_4 0xc141 OXPCIe952
product OXFORDSEMI OXPCIE952_5 0xc144 OXPCIe952
product OXFORDSEMI OXPCIE952_6 0xc145 OXPCIe952
+product OXFORDSEMI OXPCIE952_7 0xc208 OXPCIe952
/* Packet Engines products */
product PACKETENGINES GNICII 0x0911 G-NIC II Ethernet
Index: pucdata.c
===
RCS file: /cvsroot/src/sys/dev/pci/pucdata.c,v
retrieving revision 1.101
diff -u -r1.101 pucdata.c
--- pucdata.c 13 Apr 2018 07:57:04 - 1.101
+++ pucdata.c 7 May 2018 07:58:53 -
@@ -1108,6 +1108,19 @@
},
},
+ /* Oxford Semiconductor OXPCIe952 PCIe UARTs */
+ { "Oxford Semiconductor OXPCIe952 UART",
+ { PCI_VENDOR_OXFORDSEMI, PCI_PRODUCT_OXFORDSEMI_OXPCIE952_7,
+ 0, 0 },
+ { 0x, 0x, 0, 0 },
+ {
+ { PUC_PORT_TYPE_COM, PCI_BAR0, 0x1000, COM_FREQ },
+ { PUC_PORT_TYPE_COM, PCI_BAR0, 0x1200, COM_FREQ },
+ { PUC_PORT_TYPE_COM, PCI_BAR0, 0x1400, COM_FREQ },
+ { PUC_PORT_TYPE_COM, PCI_BAR0, 0x1600, COM_FREQ },
+ },
+ },
+
/* Oxford Semiconductor OXmPCI952 PCI UARTs */
{ "Oxford Semiconductor OXmPCI952 UARTs",
{ PCI_VENDOR_OXFORDSEMI, PCI_PRODUCT_OXFORDSEMI_EXSYS_EX41092,
