ell.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Ackermann, Eric" <Eric.Ackermann@student.hpi.uni-potsdam.de>
To: "ell@lists.linux.dev" <ell@lists.linux.dev>
Subject: [PATCH] Y2038 bug on uClibc: Warn if sizeof(time_t) < 8 during configuration
Date: Sun, 21 May 2023 16:19:25 +0000	[thread overview]
Message-ID: <eee3edcf43a547e1bd8d4f09ea46c168@student.hpi.uni-potsdam.de> (raw)

Hello everyone,

I discovered a Y2038 bug in iwd that was caused by the TLS certificate parsing code in ell.
I compiled iwd for Linux with uClibc on armv7l. The test "EAPoL/8021x EAP-TLS & 4-Way 
Handshake" failed with an assertion failure, as ell considered the certificate used in the 
test invalid. The reason for this is that the expiration date of the test certificate was in 2050,
which cannot be represented in uClibc's 4-byte time_t. Hence, timegm() fails, causing a 
failure of cert_parse_asn1_time() and so on.
I reckon that the issue is specific to uClibc and other C libraries that use a 4-byte time_t on
32 bit platforms, e.g., uClibc as configured by buildroot. Most C libraries (e.g. glibc, musl) 
simply define time_t to always be 64 bits long, avoiding the issue.
However, especially on embedded systems that use uClibc, this is a real issue that might 
cause unexpected behavior. Unfortunately, to my knowledge, there is no portable version
of timegm that always uses a 64-bit output. However, in my opinion, I believe that the C 
library rather than ell should be changed. For the time being (and for users who use 
unpatched versions of C libraries), the appended patch adds a warning to configure in case 
sizeof(time_t) < 8 bytes.

Kind regards,
Eric Ackermann
---
 configure.ac | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/configure.ac b/configure.ac
index fb7a997..23e719b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -31,6 +31,18 @@ AC_C_BIGENDIAN(little_endian=no, little_endian=yes, little_endian=no)
 LT_PREREQ(2.2)
 LT_INIT([disable-static])

+AC_CHECK_SIZEOF([time_t])
+SIZEOF_TIME_T=$($AWK '/SIZEOF_TIME_T/{print $3}' confdefs.h)
+if (test "${SIZEOF_TIME_T}" -lt "8"); then
+       AC_MSG_WARN([sizeof(time_t) is less than 8 bytes on your
+                    platform. Hence, dates after 2038-01-19 cannot be
+                    represented in a time_t. This might lead to overflow
+                    errors in time processing functions such as timegm,
+                    which can manifest themselves e.g. by TLS certificates
+                    with an expiration date after 2038 not being accepted
+                    by ell. Proceed with caution.])
+fi
+
 AC_ARG_ENABLE(optimization, AS_HELP_STRING([--disable-optimization],
                        [disable code optimization through compiler]), [
        if (test "${enableval}" = "no"); then
--
2.25.1

                 reply	other threads:[~2023-05-21 16:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eee3edcf43a547e1bd8d4f09ea46c168@student.hpi.uni-potsdam.de \
    --to=eric.ackermann@student.hpi.uni-potsdam.de \
    --cc=ell@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).