Re: FreeBSD Security Advisory FreeBSD-SA-18:01.ipsec

2018-03-07 Thread Christoph Moench-Tegeder
Hi,

the committed patch for FreeBSD 10.4 and 10.3 does not compile:

/usr/src/sys/netipsec/xform_ah.c:622:43: error: use of undeclared identifier
  'buf'
ipsec_address(&sav->sah->saidx.dst, buf, sizeof(buf)),
^
/usr/src/sys/netipsec/ipsec.h:323:51: note: expanded from macro 'DPRINTF'
#define DPRINTF(x)  do { if (V_ipsec_debug) printf x; } while (0)
   ^
/usr/src/sys/netipsec/xform_ah.c:625:3: error: use of undeclared identifier
  'error'
error = EACCES;
^
/usr/src/sys/netipsec/xform_ah.c:626:8: error: use of undeclared label 'bad'
goto bad;
 ^
3 errors generated.
*** Error code 1


Looking at the code, the compiler is right - things have shifted here
in between FreeBSD 10 and 11, and what's working in 11 is not good for 10...
I guess we need this additional patch:

--- sys/netipsec/xform_ah.c.orig2018-03-07 12:27:58.645874000 +0100
+++ sys/netipsec/xform_ah.c 2018-03-07 12:28:47.584073000 +0100
@@ -619,11 +619,10 @@
DPRINTF(("%s: bad mbuf length %u (expecting %lu)"
" for packet in SA %s/%08lx\n", __func__,
m->m_pkthdr.len, (u_long) (skip + authsize + rplen),
-   ipsec_address(&sav->sah->saidx.dst, buf, sizeof(buf)),
+   ipsec_address(&sav->sah->saidx.dst),
(u_long) ntohl(sav->spi)));
AHSTAT_INC(ahs_badauthl);
-   error = EACCES;
-   goto bad;
+   return EACCES;
}
AHSTAT_ADD(ahs_ibytes, m->m_pkthdr.len - skip - hl);
 

But you'd better re-check, I don't know the code here - I'm just making
stuff compile :)

Further, neither this (SA-18:01) nor SA-18:02's nor the Errata Note's
(EN-18:01, EN-18:02) do show up in the given location:
https://www.freebsd.org/security/patches/SA-18%3A01/ (and the other
directories) only have the GPG signatures, but not the patches itself.

Regards,
Christoph

-- 
Spare Space


signature.asc
Description: PGP signature


Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

2018-03-07 Thread David Chisnall
Were these changes and the kernel changes tested together on Xen?  After 
updating to -p7, I get about 10 seconds of uptime on a Xen VM before the kernel 
panics with a double fault and reboots.  Disabling ntpd results in a stable 
system.  On an AMD system without a hypervisor, I don’t see any instability.

David

> On 7 Mar 2018, at 07:10, FreeBSD Security Advisories 
>  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> =
> FreeBSD-SA-18:02.ntpSecurity Advisory
>  The FreeBSD Project
> 
> Topic:  Multiple vulnerabilities of ntp
> 
> Category:   contrib
> Module: ntp
> Announced:  2018-03-07
> Credits:Network Time Foundation
> Affects:All supported versions of FreeBSD.
> Corrected:  2018-02-28 09:01:03 UTC (stable/11, 11.1-STABLE)
>2018-03-07 05:58:24 UTC (releng/11.1, 11.1-RELEASE-p7)
>2018-03-01 04:06:49 UTC (stable/10, 10.4-STABLE)
>2018-03-07 05:58:24 UTC (releng/10.4, 10.4-RELEASE-p6)
>2018-03-07 05:58:24 UTC (releng/10.3, 10.3-RELEASE-p27)
> CVE Name:   CVE-2018-7182, CVE-2018-7170, CVE-2018-7184, CVE-2018-7185,
>CVE-2018-7183
> 
> For general information regarding FreeBSD Security Advisories,
> including descriptions of the fields above, security branches, and the
> following sections, please visit https://security.FreeBSD.org/>.
> 
> I.   Background
> 
> The ntpd(8) daemon is an implementation of the Network Time Protocol (NTP)
> used to synchronize the time of a computer system to a reference time
> source.
> 
> II.  Problem Description
> 
> The ctl_getitem() function is used by ntpd(8) to process incoming "mode 6"
> packets.  A malicious "mode 6" packet can be sent to an ntpd instance, and
> if the ntpd instance is from 4.2.8p6 through 4.2.8p10, ctl_getitem() will
> read past the end of its buffer. [CVE-2018-7182]
> 
> The ntpd(8) service can be vulnerable to Sybil attacks.  If a system is
> configured to use a trustedkey and if one is not using the feature introduced
> in ntp-4.2.8p6 allowing an optional 4th field in the ntp.keys file to specify
> which IPs can serve time, a malicious authenticated peer, i.e., one where the
> attacker knows the private symmetric key, can create arbitrarily-many
> ephemeral associations in order to win the clock selection of ntpd and modify
> a victim's clock. [CVE-2018-7170]
> 
> The fix for NtpBug2952 was incomplete, and while it fixed one problem it
> created another.  Specifically, it drops bad packets before updating the
> "received" timestamp.  This means a third-party can inject a packet with
> a zero-origin timestamp, meaning the sender wants to reset the association,
> and the transmit timestamp in this bogus packet will be saved as the most
> recent "received" timestamp.  The real remote peer does not know this
> value and this will disrupt the association until the association resets.
> [CVE-2018-7184]
> 
> The NTP Protocol allows for both non-authenticated and authenticated
> associations, in client/server, symmetric (peer), and several broadcast
> modes.  In addition to the basic NTP operational modes, symmetric mode and
> broadcast servers can support an interleaved mode of operation.  In
> ntp-4.2.8p4, a bug was inadvertently introduced into the protocol engine that
> allows a non-authenticated zero-origin (reset) packet to reset an
> authenticated interleaved peer association.  If an attacker can send a packet
> with a zero-origin timestamp and the source IP address of the "other side" of
> an interleaved association, the 'victim' ntpd will reset its association.
> The attacker must continue sending these packets in order to maintain the
> disruption of the association.  [CVE-2018-7185]
> 
> The ntpq(8) utility is a monitoring and control program for ntpd.  The
> internal decodearr() function of ntpq(8) that is used to decode an array in
> a response string when formatted data is being displayed.  This is a problem
> in affected versions of ntpq if a maliciously-altered ntpd returns an array
> result that will trip this bug, or if a bad actor is able to read an ntpq(8)
> request on its way to a remote ntpd server and forge and send a response
> before the remote ntpd sends its response.  It is potentially possible that
> the malicious data could become injectable/executable code. [CVE-2017-7183]
> 
> III. Impact
> 
> Malicious remote attackers may be able to break time synchornization,
> or cause the ntpq(8) utility to crash.
> 
> IV.  Workaround
> 
> No workaround is available, but systems not running ntpd(8) or ntpq(8) are
> not affected.  Network administrators are advised to implement BCP-38 which
> helps to reduce risk associated with the attacks.
> 
> V.   Solution
> 
> Perform one of the following:
> 
> 1) Upgrade your vulnerabl

Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

2018-03-07 Thread Remko Lodder


> On 7 Mar 2018, at 12:50, David Chisnall  wrote:
> 
> Were these changes and the kernel changes tested together on Xen?  After 
> updating to -p7, I get about 10 seconds of uptime on a Xen VM before the 
> kernel panics with a double fault and reboots.  Disabling ntpd results in a 
> stable system.  On an AMD system without a hypervisor, I don’t see any 
> instability.
> 
> David
> 
>> 

Hi David,

We have no Xen setup as far as I know so in short; these changes were not 
tested on Xen as far as I know.

Cheers
Remko



signature.asc
Description: Message signed with OpenPGP


Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

2018-03-07 Thread Trond Endrestøl
On Wed, 7 Mar 2018 14:30+0100, Remko Lodder wrote:

> > On 7 Mar 2018, at 12:50, David Chisnall  wrote:
> > 
> > Were these changes and the kernel changes tested together on Xen?  
> > After updating to -p7, I get about 10 seconds of uptime on a Xen 
> > VM before the kernel panics with a double fault and reboots.  
> > Disabling ntpd results in a stable system.  On an AMD system 
> > without a hypervisor, I don’t see any instability.
> 
> Hi David,
> 
> We have no Xen setup as far as I know so in short; these changes were not 
> tested on Xen as far as I know.
> 
> Cheers
> Remko

Here's one of my systems, running ntpd on stable/11 r330228 on 
XenServer 7.3, and there have been no issues so far. Timekeeping is as 
good as can be expected. The XenServer host has Intel CPUs.

$ uname -aKU
FreeBSD somehost 11.1-STABLE FreeBSD 11.1-STABLE #0 r330228: Thu Mar  1 
10:58:45 CET 2018 root@somehost:/usr/obj/usr/src/sys/XENGUEST  amd64 
1101511 1101511
$ w | head -1
 2:18p.m.  up 5 days,  1:23, 1 user, load averages: 0,18 0,20 0,17

Note, I run a custom kernel eliminating most of the unneeded stuff 
when running as a/an Xen guest, see 
https://ximalas.info/~trond/create-zfs/canmount/XENGUEST-amd64-stable-11 
for details.

-- 
Trond.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"


Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

2018-03-07 Thread Remko Lodder


> On 7 Mar 2018, at 12:50, David Chisnall  wrote:
> 
> Were these changes and the kernel changes tested together on Xen?  After 
> updating to -p7, I get about 10 seconds of uptime on a Xen VM before the 
> kernel panics with a double fault and reboots.  Disabling ntpd results in a 
> stable system.  On an AMD system without a hypervisor, I don’t see any 
> instability.
> 
> David
> 
>> 

Hi David,

We have no Xen setup as far as I know so in short; these changes were not 
tested on Xen as far as I know.

Cheers
Remko



signature.asc
Description: Message signed with OpenPGP


Re: FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

2018-03-07 Thread Philip M. Gollucci
The links are 404ing

On Wed, Mar 7, 2018 at 2:10 AM, FreeBSD Security Advisories <
security-advisor...@freebsd.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> 
> =
> FreeBSD-SA-18:02.ntpSecurity
> Advisory
>   The FreeBSD
> Project
>
> Topic:  Multiple vulnerabilities of ntp
>
> Category:   contrib
> Module: ntp
> Announced:  2018-03-07
> Credits:Network Time Foundation
> Affects:All supported versions of FreeBSD.
> Corrected:  2018-02-28 09:01:03 UTC (stable/11, 11.1-STABLE)
> 2018-03-07 05:58:24 UTC (releng/11.1, 11.1-RELEASE-p7)
> 2018-03-01 04:06:49 UTC (stable/10, 10.4-STABLE)
> 2018-03-07 05:58:24 UTC (releng/10.4, 10.4-RELEASE-p6)
> 2018-03-07 05:58:24 UTC (releng/10.3, 10.3-RELEASE-p27)
> CVE Name:   CVE-2018-7182, CVE-2018-7170, CVE-2018-7184, CVE-2018-7185,
> CVE-2018-7183
>
> For general information regarding FreeBSD Security Advisories,
> including descriptions of the fields above, security branches, and the
> following sections, please visit https://security.FreeBSD.org/>.
>
> I.   Background
>
> The ntpd(8) daemon is an implementation of the Network Time Protocol (NTP)
> used to synchronize the time of a computer system to a reference time
> source.
>
> II.  Problem Description
>
> The ctl_getitem() function is used by ntpd(8) to process incoming "mode 6"
> packets.  A malicious "mode 6" packet can be sent to an ntpd instance, and
> if the ntpd instance is from 4.2.8p6 through 4.2.8p10, ctl_getitem() will
> read past the end of its buffer. [CVE-2018-7182]
>
> The ntpd(8) service can be vulnerable to Sybil attacks.  If a system is
> configured to use a trustedkey and if one is not using the feature
> introduced
> in ntp-4.2.8p6 allowing an optional 4th field in the ntp.keys file to
> specify
> which IPs can serve time, a malicious authenticated peer, i.e., one where
> the
> attacker knows the private symmetric key, can create arbitrarily-many
> ephemeral associations in order to win the clock selection of ntpd and
> modify
> a victim's clock. [CVE-2018-7170]
>
> The fix for NtpBug2952 was incomplete, and while it fixed one problem it
> created another.  Specifically, it drops bad packets before updating the
> "received" timestamp.  This means a third-party can inject a packet with
> a zero-origin timestamp, meaning the sender wants to reset the association,
> and the transmit timestamp in this bogus packet will be saved as the most
> recent "received" timestamp.  The real remote peer does not know this
> value and this will disrupt the association until the association resets.
> [CVE-2018-7184]
>
> The NTP Protocol allows for both non-authenticated and authenticated
> associations, in client/server, symmetric (peer), and several broadcast
> modes.  In addition to the basic NTP operational modes, symmetric mode and
> broadcast servers can support an interleaved mode of operation.  In
> ntp-4.2.8p4, a bug was inadvertently introduced into the protocol engine
> that
> allows a non-authenticated zero-origin (reset) packet to reset an
> authenticated interleaved peer association.  If an attacker can send a
> packet
> with a zero-origin timestamp and the source IP address of the "other side"
> of
> an interleaved association, the 'victim' ntpd will reset its association.
> The attacker must continue sending these packets in order to maintain the
> disruption of the association.  [CVE-2018-7185]
>
> The ntpq(8) utility is a monitoring and control program for ntpd.  The
> internal decodearr() function of ntpq(8) that is used to decode an array in
> a response string when formatted data is being displayed.  This is a
> problem
> in affected versions of ntpq if a maliciously-altered ntpd returns an array
> result that will trip this bug, or if a bad actor is able to read an
> ntpq(8)
> request on its way to a remote ntpd server and forge and send a response
> before the remote ntpd sends its response.  It is potentially possible that
> the malicious data could become injectable/executable code. [CVE-2017-7183]
>
> III. Impact
>
> Malicious remote attackers may be able to break time synchornization,
> or cause the ntpq(8) utility to crash.
>
> IV.  Workaround
>
> No workaround is available, but systems not running ntpd(8) or ntpq(8) are
> not affected.  Network administrators are advised to implement BCP-38 which
> helps to reduce risk associated with the attacks.
>
> V.   Solution
>
> Perform one of the following:
>
> 1) Upgrade your vulnerable system to a supported FreeBSD stable or
> release / security branch (releng) dated after the correction date.
>
> The ntpd service has to be restarted after the update.  A reboot is
> recommended but not required.
>
> 2) To update your vulnerable 

Re: FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

2018-03-07 Thread Gordon Tetlow
Sorry about that. I thought I had everything but I missed that piece. They 
should be coming shortly.

That said, I’m seeing reports of the ipsec patches for 10.x not compiling. Will 
look into that shortly. 

Gordon

> On Mar 7, 2018, at 06:40, Philip M. Gollucci  wrote:
> 
> The links are 404ing
> 
> On Wed, Mar 7, 2018 at 2:10 AM, FreeBSD Security Advisories <
> security-advisor...@freebsd.org> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>> 
>> 
>> =
>> FreeBSD-SA-18:02.ntpSecurity
>> Advisory
>>  The FreeBSD
>> Project
>> 
>> Topic:  Multiple vulnerabilities of ntp
>> 
>> Category:   contrib
>> Module: ntp
>> Announced:  2018-03-07
>> Credits:Network Time Foundation
>> Affects:All supported versions of FreeBSD.
>> Corrected:  2018-02-28 09:01:03 UTC (stable/11, 11.1-STABLE)
>>2018-03-07 05:58:24 UTC (releng/11.1, 11.1-RELEASE-p7)
>>2018-03-01 04:06:49 UTC (stable/10, 10.4-STABLE)
>>2018-03-07 05:58:24 UTC (releng/10.4, 10.4-RELEASE-p6)
>>2018-03-07 05:58:24 UTC (releng/10.3, 10.3-RELEASE-p27)
>> CVE Name:   CVE-2018-7182, CVE-2018-7170, CVE-2018-7184, CVE-2018-7185,
>>CVE-2018-7183
>> 
>> For general information regarding FreeBSD Security Advisories,
>> including descriptions of the fields above, security branches, and the
>> following sections, please visit https://security.FreeBSD.org/>.
>> 
>> I.   Background
>> 
>> The ntpd(8) daemon is an implementation of the Network Time Protocol (NTP)
>> used to synchronize the time of a computer system to a reference time
>> source.
>> 
>> II.  Problem Description
>> 
>> The ctl_getitem() function is used by ntpd(8) to process incoming "mode 6"
>> packets.  A malicious "mode 6" packet can be sent to an ntpd instance, and
>> if the ntpd instance is from 4.2.8p6 through 4.2.8p10, ctl_getitem() will
>> read past the end of its buffer. [CVE-2018-7182]
>> 
>> The ntpd(8) service can be vulnerable to Sybil attacks.  If a system is
>> configured to use a trustedkey and if one is not using the feature
>> introduced
>> in ntp-4.2.8p6 allowing an optional 4th field in the ntp.keys file to
>> specify
>> which IPs can serve time, a malicious authenticated peer, i.e., one where
>> the
>> attacker knows the private symmetric key, can create arbitrarily-many
>> ephemeral associations in order to win the clock selection of ntpd and
>> modify
>> a victim's clock. [CVE-2018-7170]
>> 
>> The fix for NtpBug2952 was incomplete, and while it fixed one problem it
>> created another.  Specifically, it drops bad packets before updating the
>> "received" timestamp.  This means a third-party can inject a packet with
>> a zero-origin timestamp, meaning the sender wants to reset the association,
>> and the transmit timestamp in this bogus packet will be saved as the most
>> recent "received" timestamp.  The real remote peer does not know this
>> value and this will disrupt the association until the association resets.
>> [CVE-2018-7184]
>> 
>> The NTP Protocol allows for both non-authenticated and authenticated
>> associations, in client/server, symmetric (peer), and several broadcast
>> modes.  In addition to the basic NTP operational modes, symmetric mode and
>> broadcast servers can support an interleaved mode of operation.  In
>> ntp-4.2.8p4, a bug was inadvertently introduced into the protocol engine
>> that
>> allows a non-authenticated zero-origin (reset) packet to reset an
>> authenticated interleaved peer association.  If an attacker can send a
>> packet
>> with a zero-origin timestamp and the source IP address of the "other side"
>> of
>> an interleaved association, the 'victim' ntpd will reset its association.
>> The attacker must continue sending these packets in order to maintain the
>> disruption of the association.  [CVE-2018-7185]
>> 
>> The ntpq(8) utility is a monitoring and control program for ntpd.  The
>> internal decodearr() function of ntpq(8) that is used to decode an array in
>> a response string when formatted data is being displayed.  This is a
>> problem
>> in affected versions of ntpq if a maliciously-altered ntpd returns an array
>> result that will trip this bug, or if a bad actor is able to read an
>> ntpq(8)
>> request on its way to a remote ntpd server and forge and send a response
>> before the remote ntpd sends its response.  It is potentially possible that
>> the malicious data could become injectable/executable code. [CVE-2017-7183]
>> 
>> III. Impact
>> 
>> Malicious remote attackers may be able to break time synchornization,
>> or cause the ntpq(8) utility to crash.
>> 
>> IV.  Workaround
>> 
>> No workaround is available, but systems not running ntpd(8) or ntpq(8) are
>> not affected.  Network administrators are advised to implement B

Re: FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

2018-03-07 Thread Harlan Stenn
I still think y'all write great security advisories, and I keep aiming
to get our "originals" up to your quality.

I hope that whoever did this got a smile out of my '--- wait for it---'
comment on the ntpq decodearr() description.  I think I added that after
many continuous hours' writing of these descriptions, and sometimes I
just succumb and let things like that slip in to make my subsequent
re-reads a bit less ponderous.

On 3/6/18 11:10 PM, FreeBSD Security Advisories wrote:
> =
> FreeBSD-SA-18:02.ntpSecurity Advisory
>   The FreeBSD Project
> 
> Topic:  Multiple vulnerabilities of ntp
> ...


-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"


Re: FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

2018-03-07 Thread Roger Marquis

Harlan Stenn wrote:

I still think y'all write great security advisories, and I keep aiming
to get our "originals" up to your quality.


High quality work to be sure.  It is still unfortunate that time had to
be wasted on this (and other ntpd advisories).  Much time and insecurity
could have been saved by migrating ntpd to ports and openntpd to base.

One too many cases exactly like this are why OpenBSD and HardenedBSD
forked of course, but it is still not at all clear why openntpd and
other tested and proven security changes haven't been pulled in to
FreeBSD.

Roger Marquis
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"


FreeBSD Security Advisory FreeBSD-SA-18:01.ipsec [REVISED]

2018-03-07 Thread FreeBSD Security Advisories
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

=
FreeBSD-SA-18:01.ipsec [REVISED]Security Advisory
  The FreeBSD Project

Topic:  ipsec validation and use-after-free

Category:   core
Module: ipsec
Announced:  2018-03-07
Credits:Maxime Villard
Affects:All supported versions of FreeBSD.
Corrected:  2018-02-24 13:04:02 UTC (stable/11, 11.1-STABLE)
2018-03-07 05:53:35 UTC (releng/11.1, 11.1-RELEASE-p7)
2018-03-07 16:55:15 UTC (stable/10, 10.4-STABLE)
2018-03-07 17:16:41 UTC (releng/10.4, 10.4-RELEASE-p7)
2018-03-07 17:16:41 UTC (releng/10.3, 10.3-RELEASE-p28)
CVE Name:   CVE-2018-6916

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit https://security.FreeBSD.org/>.

0.   Revision History

v1.0  2018-03-07 Initial release.
v1.1  2018-03-08 Correct patch for 10.x releases.

I.   Background

The IPsec suite of protocols provide network level security for IPv4 and IPv6
packets.  FreeBSD includes software originally developed by the KAME project
which implements the various protocols that make up IPsec.

In IPsec, the IP Authentication Header (AH) is used to provide protection
against replay attacks and connectionless integrity and data origin
authentication for IP datagrams.

II.  Problem Description

Due to a lack of strict checking, an attacker from a trusted host can
send a specially constructed IP packet that may lead to a system crash.

Additionally, a use-after-free vulnerability in the AH handling code could
cause unpredictable results.

III. Impact

Access to out of bounds or freed mbuf data can lead to a kernel panic or
other unpredictable results.

IV.  Workaround

No workaround is available, but systems not using IPsec are not vulnerable.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
And reboot the system.

2) To update your vulnerable system via a binary patch:

Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:

# freebsd-update fetch
# freebsd-update install
And reboot the system

3) To update your vulnerable system via a source code patch:

The following patches have been verified to apply to the applicable
FreeBSD release branches.

[*** v1.1 NOTE ***] If your 10.x sources were already patched using the
initially published advisory patches, you need to apply the
ipsec-10.rev1.patch. If you had not yet patched your 10.x sources, you need
only apply the ipsec-10.patch file. 11.1 sources were correct in the initial
release and do not need to be updated.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 10.x system not patched with the original SA-18:01 patch]
# fetch https://security.FreeBSD.org/patches/SA-18:01/ipsec-10.patch
# fetch https://security.FreeBSD.org/patches/SA-18:01/ipsec-10.patch.asc
# gpg --verify ipsec-10.patch.asc

[FreeBSD 10.x that had been patched with the original SA-18:01 patch]
# fetch https://security.FreeBSD.org/patches/SA-18:01/ipsec-10.rev1.patch
# fetch https://security.FreeBSD.org/patches/SA-18:01/ipsec-10.rev1.patch.asc
# gpg --verify ipsec-10.rev1.patch.asc

[FreeBSD 11.1]
# fetch https://security.FreeBSD.org/patches/SA-18:01/ipsec-11.patch
# fetch https://security.FreeBSD.org/patches/SA-18:01/ipsec-11.patch.asc
# gpg --verify ipsec-11.patch.asc

b) Apply the patch.  Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch

c) Recompile your kernel as described in
https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.

VI.  Correction details

The following list contains the correction revision numbers for each
affected branch.

Branch/path  Revision
- -
stable/10/r330609
releng/10.3/  r330611
releng/10.4/  r330611
stable/11/r329907
releng/11.1/  r330566
- -

To see which files were modified by a particular revision, run the
following command, replacing NN with the revision number, on a
machine with Subversion installed:

# svn diff -cNN --summarize svn://svn.freebsd.org/base

Or visit the follo