os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add SA-18:08.tcp.

Browse source
This commit is contained in:
Xin LI 2018-08-06 20:44:33 +00:00
parent c4c50e5c5d
commit 89a63a90b2
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=52082
6 changed files with 331 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

168
share/security/advisories/FreeBSD-SA-18:08.tcp.asc Normal file
View file

@ -0,0 +1,168 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-18:08.tcp Security Advisory
The FreeBSD Project
Topic: Resource exhaustion in TCP reassembly
Category: core
Module: inet
Announced: 2018-08-06
Credits: Juha-Matti Tilli <juha-matti.tilli@iki.fi> from
Aalto University, Department of Communications and Networking
and Nokia Bell Labs
Affects: All supported versions of FreeBSD.
Corrected: 2018-08-06 18:46:09 UTC (stable/11, 11.1-STABLE)
2018-08-06 17:47:47 UTC (releng/11.2, 11.2-RELEASE-p1)
2018-08-06 17:48:46 UTC (releng/11.1, 11.1-RELEASE-p12)
2018-08-06 18:47:03 UTC (stable/10, 10.4-STABLE)
2018-08-06 17:50:40 UTC (releng/10.4, 10.4-RELEASE-p10)
CVE Name: CVE-2018-6922
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:https://security.FreeBSD.org/>.
I. Background
The Transmission Control Protocol (TCP) of the TCP/IP protocol suite
provides a connection-oriented, reliable, sequence-preserving data
stream service.
To transmit a stream of data, TCP breaks the data stream into segments
for transmission through the Internet, and reassembles the segments at
the receiving side to recreate the data stream.
II. Problem Description
One of the data structures that holds TCP segments uses an inefficient
algorithm to reassemble the data. This causes the CPU time spent on
segment processing to grow linearly with the number of segments in the
reassembly queue.
III. Impact
An attacker who has the ability to send TCP traffic to a victim system
can degrade the victim system's network performance and/or consume
excessive CPU by exploiting the inefficiency of TCP reassembly
handling, with relatively small bandwidth cost.
IV. Workaround
As a workaround, system administrators should configure their systems
to only accept TCP connections from trusted end-stations, if it is
possible to do so.
For systems which must accept TCP connections from untrusted
end-stations, the workaround is to limit the size of each reassembly
queue. The capability to do that is added by the patches noted in the
"Solution" section below.
V. Solution
As a temporary solution to this problem, these patches limit the size
of each TCP connection's reassembly queue. The value is controlled by
a sysctl (net.inet.tcp.reass.maxqueuelen), which sets the maximum
number of TCP segments that can be outstanding on a session's
reassembly queue. This value defaults to 100.
Note that setting this value too low could impact the throughput of
TCP connections which experience significant loss or
reordering. However, the higher this number is set, the more resources
can be consumed on TCP reassembly processing.
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.
Afterward, 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
Afterward, 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.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 10.4]
# fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-10.patch
# fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-10.patch.asc
# gpg --verify tcp-10.patch.asc
[FreeBSD 11.x]
# fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-11.patch
# fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-11.patch.asc
# gpg --verify tcp-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
<URL: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/ r337392
releng/10.4/ r337389
stable/11/ r337391
releng/11.1/ r337388
releng/11.2/ r337387
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
VII. References
<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6922>
<URL:https://www.kb.cert.org/vuls/id/962459>
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-18:08.tcp.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.9 (FreeBSD)
iQIzBAEBCgAdFiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAltosd4ACgkQ05eS9J6n
5cKLRRAApitUTx46nToGtbCr/fzEZtYpjU0L/kMDwFw8ngfrb3MR4yht087t8JK1
jZlbeKRQwYjN+ecLrO3QdWoM4LavQK/cYuWq2tCpJiwqXK15rDJGBJjlBiAsmupF
fGGSD2DcJ/Jz7zTKDkjybCh83QGGTt/HBZRYLc85ipJPHgPQQtnD/OLjFK34Lr45
vEss9AAkBEe4ZWiSltrQYzqMYf8+sCz/OYP+NGluz4eUjuzKogqyLIAA29auqoNp
UY5tIUhf8dcB9oeARxWlvmxTKSLB5kevF5jsBzxB8Ap1xUfLFip02h6ApL0xuWz2
ouX/gN8KBgmJoNIP+GbBY29sQCEY0GTIR9q/dO1ZB3CePJFQsvWjtNeBBjIK66On
xJSSrUXDPANfcePbnCN9JdsclSEJ0+EBYol3hSWVY8bX3OMcOZw1wRXXCwN0T3of
QQwbuP0ORt5OdsOObwaxDJEWLEma7N2swWF5YR0oQl0+ETvkIsqFilsTlY6qEB/L
WG9G1Y9uVn++AJs7HzI+vKVEhhwtJep+7ks28sH5J0LQiUGYfwRACYfVLgi6iXNV
YKPB4hUFd2d8QaYWdgU92YBJWrR8bqyDdetifMEG5tP+TFCeNCh6SMpRnL7Lzns+
hkZiRHJeIT7tGu77xZknFI6ghDHOdemtZ/QiL0NsrM05spWkdIA=
=HNsD
-----END PGP SIGNATURE-----

58
share/security/patches/SA-18:08/tcp-10.patch Normal file
View file

@ -0,0 +1,58 @@
--- share/man/man4/tcp.4.orig
+++ share/man/man4/tcp.4
@@ -436,6 +436,20 @@
Reseeding should not be necessary, and will break
.Dv TIME_WAIT
recycling for a few minutes.
+.It Va reass.cursegments
+The current total number of segments present in all reassembly queues.
+.It Va reass.maxsegments
+The maximum limit on the total number of segments across all reassembly
+queues.
+The limit can be adjusted as a tunable.
+.It Va reass.maxqueuelen
+The maximum number of segments allowed in each reassembly queue.
+By default, the system chooses a limit based on each TCP connection's
+receive buffer size and maximum segment size (MSS).
+The actual limit applied to a session's reassembly queue will be the lower of
+the system-calculated automatic limit and the user-specified
+.Va reass.maxqueuelen
+limit.
.It Va rexmit_min , rexmit_slop
Adjust the retransmit timer calculation for
.Tn TCP .
--- sys/netinet/tcp_reass.c.orig
+++ sys/netinet/tcp_reass.c
@@ -96,6 +96,11 @@
static uma_zone_t tcp_reass_zone;
+static u_int tcp_reass_maxqueuelen = 100;
+SYSCTL_UINT(_net_inet_tcp_reass, OID_AUTO, maxqueuelen, CTLFLAG_RWTUN,
+ &tcp_reass_maxqueuelen, 0,
+ "Maximum number of TCP Segments per Reassembly Queue");
+
/* Initialize TCP reassembly queue */
static void
tcp_reass_zone_change(void *tag)
@@ -184,6 +189,10 @@
* socket receive buffer determines our advertised window and grows
* automatically when socket buffer autotuning is enabled. Use it as the
* basis for our queue limit.
+ *
+ * However, allow the user to specify a ceiling for the number of
+ * segments in each queue.
+ *
* Always let the missing segment through which caused this queue.
* NB: Access to the socket buffer is left intentionally unlocked as we
* can tolerate stale information here.
@@ -194,7 +203,8 @@
* is understood.
*/
if ((th->th_seq != tp->rcv_nxt || !TCPS_HAVEESTABLISHED(tp->t_state)) &&
- tp->t_segqlen >= (so->so_rcv.sb_hiwat / tp->t_maxseg) + 1) {
+ tp->t_segqlen >= min((so->so_rcv.sb_hiwat / tp->t_maxseg) + 1,
+ tcp_reass_maxqueuelen)) {
tcp_reass_overflows++;
TCPSTAT_INC(tcps_rcvmemdrop);
m_freem(m);

17
share/security/patches/SA-18:08/tcp-10.patch.asc Normal file
View file

@ -0,0 +1,17 @@
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.9 (FreeBSD)
iQIzBAABCgAdFiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAltoscgACgkQ05eS9J6n
5cJuNg/+JNxnU+NrabjbLdTzRsZ7tFfN0VlS4JQqih7AscM5Fb5/WxLZAoZV7j1B
+emSDdXWD6EHgs9zYDhCuBgj4tqxiEnccsxuY2AJmE5esdq5igwkTGHlsAjmhJan
gxvqbkzlKvSG4CD/tm+haESfnh3pnlYKnGyiSTItDG+m5Cy4yBD/bfpJ+BkcihdL
nT1AakwnaY/i+fYQlZ+RbMmKwIJfuG+rnMFo0haPKA866PRseawSqzcNDYi0WWEH
BNetby5fcn9wjaIzI8ocMtqaK4ck5JCVAX9J9NlmFOFEPAJY2teFRpV9b8bv2yZ/
y2ddLXo9/LT8jK+xMu7bCzcIJd35qJqgykdJ7Bi7xR3wwXjcgQEKThqNsa/gosUD
fapQcz9Pfb8zAUYjxk8FkGH3oloXcMUE3TT8mgwzx5QhA9QtOE/zNaq5sdB4Z40d
+tHN3dleEYDMCzpkgZfXtqEhJ9eB3gT4oam8v/nO9is8r33I1n32OFdzz5F6BT0+
XY59fju8IbUwrfClSgEZh0pImrvhmuxy5Z2HuJrwFV8L2dLN4EveybWt0FZCVLH0
R4Ob8qWwmXBC7IH9DfcE3B3NbrT57/4CfO6t3APiElFKmVwBOPi8/L15+bnBeu5n
nRddTuuAOtwTJRishobLGuBPQZsx3X4y6eOBKcG7HAJb/no5JxA=
=t1Cq
-----END PGP SIGNATURE-----

58
share/security/patches/SA-18:08/tcp-11.patch Normal file
View file

@ -0,0 +1,58 @@
--- share/man/man4/tcp.4.orig
+++ share/man/man4/tcp.4
@@ -445,6 +445,20 @@
Reseeding should not be necessary, and will break
.Dv TIME_WAIT
recycling for a few minutes.
+.It Va reass.cursegments
+The current total number of segments present in all reassembly queues.
+.It Va reass.maxsegments
+The maximum limit on the total number of segments across all reassembly
+queues.
+The limit can be adjusted as a tunable.
+.It Va reass.maxqueuelen
+The maximum number of segments allowed in each reassembly queue.
+By default, the system chooses a limit based on each TCP connection's
+receive buffer size and maximum segment size (MSS).
+The actual limit applied to a session's reassembly queue will be the lower of
+the system-calculated automatic limit and the user-specified
+.Va reass.maxqueuelen
+limit.
.It Va rexmit_min , rexmit_slop
Adjust the retransmit timer calculation for
.Tn TCP .
--- sys/netinet/tcp_reass.c.orig
+++ sys/netinet/tcp_reass.c
@@ -89,6 +89,11 @@
&tcp_reass_zone,
"Global number of TCP Segments currently in Reassembly Queue");
+static u_int tcp_reass_maxqueuelen = 100;
+SYSCTL_UINT(_net_inet_tcp_reass, OID_AUTO, maxqueuelen, CTLFLAG_RWTUN,
+ &tcp_reass_maxqueuelen, 0,
+ "Maximum number of TCP Segments per Reassembly Queue");
+
/* Initialize TCP reassembly queue */
static void
tcp_reass_zone_change(void *tag)
@@ -168,6 +173,10 @@
* socket receive buffer determines our advertised window and grows
* automatically when socket buffer autotuning is enabled. Use it as the
* basis for our queue limit.
+ *
+ * However, allow the user to specify a ceiling for the number of
+ * segments in each queue.
+ *
* Always let the missing segment through which caused this queue.
* NB: Access to the socket buffer is left intentionally unlocked as we
* can tolerate stale information here.
@@ -178,7 +187,8 @@
* is understood.
*/
if ((th->th_seq != tp->rcv_nxt || !TCPS_HAVEESTABLISHED(tp->t_state)) &&
- tp->t_segqlen >= (so->so_rcv.sb_hiwat / tp->t_maxseg) + 1) {
+ tp->t_segqlen >= min((so->so_rcv.sb_hiwat / tp->t_maxseg) + 1,
+ tcp_reass_maxqueuelen)) {
TCPSTAT_INC(tcps_rcvreassfull);
*tlenp = 0;
if ((s = tcp_log_addrs(&tp->t_inpcb->inp_inc, th, NULL, NULL))) {

17
share/security/patches/SA-18:08/tcp-11.patch.asc Normal file
View file

@ -0,0 +1,17 @@
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.9 (FreeBSD)
iQIzBAABCgAdFiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAltosdMACgkQ05eS9J6n
5cJHEBAAkJVtQ+WaIfr7rYpBIBY04ZMEClsVQ8RDJWVAsiQpG7KzqoPAblUWwJU1
k1lMkZ+vRnt6tfgvdaud16TT+73Tum/Tdgra04gRLEbw3TAkus00RjEseWU5tHEn
GxSgGNTlUkCfNLEA0GYtkpfoIwhdG06/Gm/9MBxmhexZWwo1WpzVgoDCvJy0lStS
Jw/uHM3gm7you1Ei3d/XV0Y8Xoanaz23DHqKbkeFIwc0KqGFzvN9+eo6Ff/NBgqP
XC5y3J/SCNsBnFCbmzeN373IK0N5C1X27Pb9rW3eDkQ+X3+jQXoezeKuisJP59Q7
FgfXa3bTtH5ac98ZR7QrPOq2TW/cQBS71zt4AaEIrogMOiFTcy9sdjjy5IUhfKdk
t6VhAJpq4t7tE66iYMr9wl9XdWxfMIkqrV7ejDWYErhPUIzXPR0vbJ4HM8FswnoG
LkOYJjmn4ZtTIJopjZH0qYdx0IfZsGIcqvCkEMfc2xIHqa2JDn11dGsYwzDxh51R
aoSHXiG8TqbyaAUIlcWyDizlxfppr0UugubbriTnbkuHGRgSJ/IMLArkU7LaUJB7
122q1fvY0uEW404MbncGN+PMYayjRKVdM2gW1BKIQhAnq6y8ll8+7ExkqFsTSzoO
ad5fFUg9E8JIWDFj8R2CS3RKAQ9NtzOic8iuQQp4lijp1NjoIZE=
=RTv1
-----END PGP SIGNATURE-----

13
share/xml/advisories.xml
View file

@ -7,6 +7,19 @@
<year>
<name>2018</name>
<month>
<name>8</name>
<day>
<name>6</name>
<advisory>
<name>FreeBSD-SA-18:08.tcp</name>
</advisory>
</day>
</month>
<month>
<name>6</name>