From nobody Mon Aug 12 20:41:35 2024 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WjRJP5414z5T6qj; Mon, 12 Aug 2024 20:41:41 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WjRJP2JXnz4RNG; Mon, 12 Aug 2024 20:41:41 +0000 (UTC) (envelope-from tuexen@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:c965:bc32:9a61:38c2]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 5AF05721E2806; Mon, 12 Aug 2024 22:41:36 +0200 (CEST) Content-Type: text/plain; charset=us-ascii List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: git: 9b569353e0b0 - main - tcp: initialize V_ts_offset_secret for all vnets From: tuexen@freebsd.org In-Reply-To: Date: Mon, 12 Aug 2024 22:41:35 +0200 Cc: Zhenlei Huang , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" , FreeBSD Security Team Content-Transfer-Encoding: quoted-printable Message-Id: <87B7ADB0-5FEE-4ACA-A0E3-492CDB1A1DD1@freebsd.org> References: <202408091415.479EF480062250@gitrepo.freebsd.org> <640CAD45-A146-45D1-AFAD-7FDC6B9F6006@freebsd.org> To: Mark Johnston X-Mailer: Apple Mail (2.3776.700.51) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE] X-Rspamd-Queue-Id: 4WjRJP2JXnz4RNG > On 12. Aug 2024, at 17:20, Mark Johnston wrote: >=20 > On Sat, Aug 10, 2024 at 12:07:35PM +0200, tuexen@freebsd.org wrote: >>> On 10. Aug 2024, at 02:20, Zhenlei Huang wrote: >>>=20 >>>=20 >>>=20 >>>> On Aug 9, 2024, at 10:15 PM, Michael Tuexen = wrote: >>>>=20 >>>> The branch main has been updated by tuexen: >>>>=20 >>>> URL: = https://cgit.FreeBSD.org/src/commit/?id=3D9b569353e0b073a513cf10debbe634c2= ceb29fdf >>>>=20 >>>> commit 9b569353e0b073a513cf10debbe634c2ceb29fdf >>>> Author: Michael Tuexen >>>> AuthorDate: 2024-08-09 14:12:22 +0000 >>>> Commit: Michael Tuexen >>>> CommitDate: 2024-08-09 14:12:22 +0000 >>>>=20 >>>> tcp: initialize V_ts_offset_secret for all vnets >>>>=20 >>>> Initialize V_ts_offset_secret for each vnet, not only for the >>>> default vnet, since it is vnet specific. >>>>=20 >>>> Reviewed by: Peter Lei >>>> MFC after: 3 days >>>> Sponsored by: Netflix, Inc. >>>> Differential Revision: https://reviews.freebsd.org/D46246 >>>> --- >>>> sys/netinet/tcp_subr.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>=20 >>>> diff --git a/sys/netinet/tcp_subr.c b/sys/netinet/tcp_subr.c >>>> index 9e95a87b3596..9b5f2651fb35 100644 >>>> --- a/sys/netinet/tcp_subr.c >>>> +++ b/sys/netinet/tcp_subr.c >>>> @@ -1465,6 +1465,7 @@ tcp_vnet_init(void *arg __unused) >>>> VNET_PCPUSTAT_ALLOC(tcpstat, M_WAITOK); >>>>=20 >>>> V_tcp_msl =3D TCPTV_MSL; >>>> + arc4rand(&V_ts_offset_secret, sizeof(V_ts_offset_secret), 0); >>>=20 >>> Emm, does it have any (potential) security problems if not = initialized ? If yes then does it deserve an SA ? >> I don't know, if it deserves a SA. I plan to MFC it after 3 days and = would >> like to get it included in 13.4 (I sent a notice announcing this to = re@ >> yesterday). >>=20 >> The consequence of the bug is that the offset for the TCP timestamp = is >> predictable for all vnets not being the default vnet (vnet0). >>=20 >> So an attacker could setup TCP connections to multiple TCP endpoints >> and try to figure out >> * if they belong to the same host. >> * what the ticks value of the host is. >>=20 >> However, this requires >> (a) the attacker knows that the TCP endpoints are on a FreeBSD host. >> (b) that at least two TCP endpoints are not in vnet0. >> (c) the attacker knows the way the offset is computed. >>=20 >> (c) is a consequence of (a). >>=20 >> I also CC'ed the security team, so they are aware of it and can chime = in. >=20 > I don't really see why two endpoints are needed to figure out the = uptime Bad wording on my side. > of the host. The timestamp we use is a hash of the connection 4-tuple > and the secret, which is all zeroes for a VNET jail affected by this = bug. Correct. >=20 > One could precompute the hash outputs for some range of time values, > connect twice to the same endpoint, and check to see whether the > timestamps correspond to two of the precomputed values in a way that > roughly matches the time delta between the connections. Assuming a), > one can then infer 1) whether the endpoint is in a VNET jail, and 2) = the > uptime of the host. What I meant: If the attacker knows the four tuple and the secret, the attacker can setup a TCP connection to an end-point and can compute the ticks value. This gives an indication of the up time. If the sysctl net.inet.tcp.ts_offset_per_conn is off (not the default) and the system operates as a server, an attacker could figure out that two end points have the same ticks value and, most likely, are on the same host. >=20 > This assumes that the VNET isn't behind a NAT service, since otherwise > the 4-tuple will be different, but even then the search space might be > small enough to succeed. Correct. If the attacker doesn't see the four tuple (or the IP address pair), the ticks value can't be computed. What I was referring to are the arguments why you don't want to use TCP timestamps, if the timestamps are just the uptime. Best regards Michael