| Message ID | 20230130172936.3444840-1-arne@rfc2549.org |
|---|---|
| State | Accepted |
| Headers |
Return-Path: <openvpn-devel-bounces@lists.sourceforge.net>
Delivered-To: patchwork@openvpn.net
Received: by 2002:a05:7300:c95:b0:82:e4b3:40a0 with SMTP id p21csp3397588dyk;
Mon, 30 Jan 2023 09:30:08 -0800 (PST)
X-Google-Smtp-Source:
AMrXdXvwIG+MIvciTwQdSJKBLHvPyxARPhpcU5VwV5L6n7B9dZVXTpBXt2pxT5JTXzqOvqU5iDAD
X-Received: by 2002:a17:90a:428c:b0:223:b920:28df with SMTP id
p12-20020a17090a428c00b00223b92028dfmr52535637pjg.29.1675099807807;
Mon, 30 Jan 2023 09:30:07 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1675099807; cv=none;
d=google.com; s=arc-20160816;
b=0giu8/aWB7GfIKft7kK9UCmemkWCTeSGJ0PPvVxyR+IEe4l71ai+ZW0CPUQWYh7SBV
qjXrRYZ5UguICheigaP2Ox2YLUkvg9iZvR2NAKrNgcYYQQt3224sCaGJdrcGCzJUt0oY
CAMhc/QNOztpNa0Ke9oC7ouj+6zpG8k1r47nlHJLAd1kjhI44ISmQ9ca9ohvAjc1SQbj
DxVUOVqR7YPH7WZYOzXoxhqpUo430+M3hkcuL+ns2EQctuAyqPBRhnxTyWXKnNzQ3ava
OrjMFb+N/Lgb6QuBtR0xHG1VJ6Ox/VOHMNUMw/yht22Uw+c47VoCdNH2QN/wXI/0KioI
PS3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=errors-to:content-transfer-encoding:list-subscribe:list-help
:list-post:list-archive:list-unsubscribe:list-id:precedence:subject
:mime-version:message-id:date:to:from:dkim-signature:dkim-signature;
bh=7IaDrPVhEuiyOubH5MXUqZ8vYaFk4I6YUpqkQKqF/qU=;
b=k1BuJY/bPLHAevHjR9blxd7aX/UEOtBpnGwrgJ1qprdP4K3HTWEgEUpWE7Uj601Kql
hjl05Bq8ysYOJkvw92s6gb2n0V4C5pHsh8d0s1hJUaWjsciS1gI37i9UmYPWolpkvM4N
aAJBlfAz+Yz93rTBp8IuiI42qntC/QMOhZRJkGWZcdbkgbEVYmIq9+60c20qFB2Y0O3s
MAEqIgyj6dRGw1qoyqk4JD+aww9GfWWtxfJ961QRQ8kLOPm0QsM5Rnkt01gvh946yPo3
YkstWAyCBngLVZIGXNNk+SWWPg8m0LLygy4oXxPw1HtkFyZBc5SJQNKs7jG5wFQ/qnz2
o8/g==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=neutral (body hash did not verify) header.i=@sourceforge.net
header.s=x header.b=KeviKyGP;
dkim=neutral (body hash did not verify) header.i=@sf.net header.s=x
header.b=Vza08cXi;
spf=pass (google.com: domain of
openvpn-devel-bounces@lists.sourceforge.net designates 216.105.38.7 as
permitted sender) smtp.mailfrom=openvpn-devel-bounces@lists.sourceforge.net
Received: from lists.sourceforge.net (lists.sourceforge.net. [216.105.38.7])
by mx.google.com with ESMTPS id
q89-20020a17090a756200b00225d9c7afe2si13515750pjk.74.2023.01.30.09.30.07
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Mon, 30 Jan 2023 09:30:07 -0800 (PST)
Received-SPF: pass (google.com: domain of
openvpn-devel-bounces@lists.sourceforge.net designates 216.105.38.7 as
permitted sender) client-ip=216.105.38.7;
Authentication-Results: mx.google.com;
dkim=neutral (body hash did not verify) header.i=@sourceforge.net
header.s=x header.b=KeviKyGP;
dkim=neutral (body hash did not verify) header.i=@sf.net header.s=x
header.b=Vza08cXi;
spf=pass (google.com: domain of
openvpn-devel-bounces@lists.sourceforge.net designates 216.105.38.7 as
permitted sender) smtp.mailfrom=openvpn-devel-bounces@lists.sourceforge.net
Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com)
by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.95)
(envelope-from <openvpn-devel-bounces@lists.sourceforge.net>)
id 1pMXyV-0006Wb-Pg;
Mon, 30 Jan 2023 17:29:47 +0000
Received: from [172.30.20.202] (helo=mx.sourceforge.net)
by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLS1.2) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95)
(envelope-from <arne@kamera.blinkt.de>) id 1pMXyV-0006WQ-0w
for openvpn-devel@lists.sourceforge.net;
Mon, 30 Jan 2023 17:29:46 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=sourceforge.net; s=x; h=Content-Transfer-Encoding:MIME-Version:Message-Id:
Date:Subject:To:From:Sender:Reply-To:Cc:Content-Type:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=G+P3kdULRE/o99ESZYo3sewW2j8Y1dI2gx/lWCdGYqw=; b=KeviKyGP6TRLBC2qS50PL+RQ3L
GVNx2/eDc94Bp9D3BbtK/sEt2YRJvzcQp9FiTQGEbL4kUaZ3hR3RoBEqNfXaukVQ6jiJpg2mlzQE/
darKekLpXrZRJzxG8VTy2Ie/28eNSqdNSuj/MAQvWFmw4TyOMJbH766wPQXZe6Ql9ncI=;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x
;
h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject:To:From:
Sender:Reply-To:Cc:Content-Type:Content-ID:Content-Description:Resent-Date:
Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:
References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:
List-Owner:List-Archive; bh=G+P3kdULRE/o99ESZYo3sewW2j8Y1dI2gx/lWCdGYqw=; b=V
za08cXi7GhVnHgFPOlflcm7Z3BadzxnAvZIE1BBESncquE8pyITm+Kck7emNMKdP5TULK0rOxEYEu
9P3FTRRBrKHXfox+0V61cwbn1qZqhSc+MxIJ+xXq5+Tp24aB5dYlp6HfB13wcy2auQeOpedKCqkaF
qR60pRvDpN/qVrh0=;
Received: from mail.blinkt.de ([192.26.174.232])
by sfi-mx-1.v28.lw.sourceforge.com with esmtps
(TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95)
id 1pMXyT-003zQC-S4 for openvpn-devel@lists.sourceforge.net;
Mon, 30 Jan 2023 17:29:46 +0000
Received: from kamera.blinkt.de ([2001:638:502:390:20c:29ff:fec8:535c])
by mail.blinkt.de with smtp (Exim 4.95 (FreeBSD))
(envelope-from <arne@kamera.blinkt.de>) id 1pMXyK-000JyM-Rv
for openvpn-devel@lists.sourceforge.net;
Mon, 30 Jan 2023 18:29:36 +0100
Received: (nullmailer pid 3444888 invoked by uid 10006);
Mon, 30 Jan 2023 17:29:36 -0000
From: Arne Schwabe <arne@rfc2549.org>
To: openvpn-devel@lists.sourceforge.net
Date: Mon, 30 Jan 2023 18:29:32 +0100
Message-Id: <20230130172936.3444840-1-arne@rfc2549.org>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
X-Spam-Score: 0.3 (/)
X-Spam-Report: Spam detection software,
running on the system "util-spamd-2.v13.lw.sourceforge.com",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: The undefined behaviour USAN clang checker found this. The
optimiser of clang/gcc will optimise the memcpy away in the auth_token case
and output excactly the same assembly on amd64/arm64 but it is st [...]
Content analysis details: (0.3 points, 6.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
0.0 SPF_NONE SPF: sender does not publish an SPF Record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
mail domains are different
X-Headers-End: 1pMXyT-003zQC-S4
Subject: [Openvpn-devel] [PATCH 1/5] Fix unaligned access in auth-token
X-BeenThere: openvpn-devel@lists.sourceforge.net
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: <openvpn-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/options/openvpn-devel>,
<mailto:openvpn-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive:
<http://sourceforge.net/mailarchive/forum.php?forum_name=openvpn-devel>
List-Post: <mailto:openvpn-devel@lists.sourceforge.net>
List-Help: <mailto:openvpn-devel-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/openvpn-devel>,
<mailto:openvpn-devel-request@lists.sourceforge.net?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: openvpn-devel-bounces@lists.sourceforge.net
X-getmail-retrieved-from-mailbox: Inbox
X-GMAIL-THRID: =?utf-8?q?1756469456456892479?=
X-GMAIL-MSGID: =?utf-8?q?1756469456456892479?=
|
| Series |
[Openvpn-devel,1/5] Fix unaligned access in auth-token
|
|
Commit Message
Arne Schwabe
Jan. 30, 2023, 5:29 p.m. UTC
The undefined behaviour USAN clang checker found this. The optimiser
of clang/gcc will optimise the memcpy away in the auth_token case and output
excactly the same assembly on amd64/arm64 but it is still better to not rely
on undefined behaviour.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
---
src/openvpn/auth_token.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
Comments
On Mon, Jan 30, 2023 at 06:29:32PM +0100, Arne Schwabe wrote: > The undefined behaviour USAN clang checker found this. The optimiser > of clang/gcc will optimise the memcpy away in the auth_token case and output > excactly the same assembly on amd64/arm64 but it is still better to not rely > on undefined behaviour. > > Signed-off-by: Arne Schwabe <arne@rfc2549.org> > --- > src/openvpn/auth_token.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/src/openvpn/auth_token.c b/src/openvpn/auth_token.c > index 7b963a9c5..e4486eb08 100644 > --- a/src/openvpn/auth_token.c > +++ b/src/openvpn/auth_token.c > @@ -324,8 +324,14 @@ verify_auth_token(struct user_pass *up, struct tls_multi *multi, > const uint8_t *tstamp_initial = sessid + AUTH_TOKEN_SESSION_ID_LEN; > const uint8_t *tstamp = tstamp_initial + sizeof(int64_t); > > - uint64_t timestamp = ntohll(*((uint64_t *) (tstamp))); > - uint64_t timestamp_initial = ntohll(*((uint64_t *) (tstamp_initial))); > + /* tstamp, tstamp_initial might not be aligned to an uint64, use memcpy > + * to avoid unaligned access */ > + uint64_t timestamp = 0, timestamp_initial = 0; > + memcpy(×tamp, tstamp, sizeof(uint64_t)); > + timestamp = ntohll(timestamp); > + > + memcpy(×tamp_initial, tstamp_initial, sizeof(uint64_t)); > + timestamp_initial = ntohll(timestamp_initial); > > hmac_ctx_t *ctx = multi->opt.auth_token_key.hmac; > if (check_hmac_token(ctx, b64decoded, up->username)) Acked-By: Frank Lichtenheld <frank@lichtenheld.com> Trivial enough. Regards,
This one is fairly straightforward. We had discussions on IRC if
we really need to make this network byte order ("the data in the token
is only for the server, nobody else needs to care") but then decided
that if someone wants to run a cluster of an intel + a s390 host,
they need to be compatible wrt timestamp representation...
Tested on the server testbed, just to be sure (it has an auth-token test) -
things still work, including token expiry after the configured time.
Your patch has been applied to the master and release/2.6 branch (bugfix).
commit f6ccff6d7ea806711f9af59c9de52b7cf80d9c81 (master)
commit 6241b2f8dbe39062a3273499a0259750d2f02cf8 (release/2.6)
Author: Arne Schwabe
Date: Mon Jan 30 18:29:32 2023 +0100
Fix unaligned access in auth-token
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Frank Lichtenheld <frank@lichtenheld.com>
Message-Id: <20230130172936.3444840-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26103.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
--
kind regards,
Gert Doering
diff --git a/src/openvpn/auth_token.c b/src/openvpn/auth_token.c index 7b963a9c5..e4486eb08 100644 --- a/src/openvpn/auth_token.c +++ b/src/openvpn/auth_token.c @@ -324,8 +324,14 @@ verify_auth_token(struct user_pass *up, struct tls_multi *multi, const uint8_t *tstamp_initial = sessid + AUTH_TOKEN_SESSION_ID_LEN; const uint8_t *tstamp = tstamp_initial + sizeof(int64_t); - uint64_t timestamp = ntohll(*((uint64_t *) (tstamp))); - uint64_t timestamp_initial = ntohll(*((uint64_t *) (tstamp_initial))); + /* tstamp, tstamp_initial might not be aligned to an uint64, use memcpy + * to avoid unaligned access */ + uint64_t timestamp = 0, timestamp_initial = 0; + memcpy(×tamp, tstamp, sizeof(uint64_t)); + timestamp = ntohll(timestamp); + + memcpy(×tamp_initial, tstamp_initial, sizeof(uint64_t)); + timestamp_initial = ntohll(timestamp_initial); hmac_ctx_t *ctx = multi->opt.auth_token_key.hmac; if (check_hmac_token(ctx, b64decoded, up->username))