linux-kernel - Re: [PATCH v2] initramfs: Check timestamp to prevent broken cpio archive

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 12 Oct 2021 21:59:46 +0200
From:   Nicolas Schier <nicolas@...sle.eu>
To:     Masahiro Yamada <masahiroy@...nel.org>,
        linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org
Cc:     Thomas Kühnel <thomas.kuehnel@....de>
Subject: Re: [PATCH v2] initramfs: Check timestamp to prevent broken cpio
 archive

On Tue 12 Oct 2021 18:52:34 GMT Nicolas Schier wrote:
> Cpio format reserves 8 bytes for an ASCII representation of a time_t 
> timestamp.
> While 2106-02-07 06:28:15 UTC (time_t = 0xffffffff) is still some years in the
> future, a poorly chosen date string for KBUILD_BUILD_TIMESTAMP, converted into
> seconds since the epoch, might lead to exceeded cpio timestamp limits that
> result in a broken cpio archive.  Add timestamp checks to prevent overrun of
> the 8-byte cpio header field.
> 
> My colleague Thomas Kühnel discovered the behaviour, when we accidentally fed
> SOURCE_DATE_EPOCH to KBUILD_BUILD_TIMESTAMP as is: some timestamps (e.g.
> 1607420928 = 2021-12-08 10:48:48) will be interpreted by `date` as a valid date
> specification of science fictional times (here: year 160742).  Even though this
> is bad input for KBUILD_BUILD_TIMESTAMP, it should not break the initramfs
> cpio format.
> 
> Signed-off-by: Nicolas Schier <nicolas@...sle.eu>
> Cc: Thomas Kühnel <thomas.kuehnel@....de>
> ---
>  usr/gen_init_cpio.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> -- 
> Changes v1 to v2:
>   * add timezone name (UTC) to specific time stamps
>   * fix typo: results -> result 
> 
> diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c
> index 03b21189d58b..584ea45cff70 100644
> --- a/usr/gen_init_cpio.c
> +++ b/usr/gen_init_cpio.c
> @@ -320,6 +320,12 @@ static int cpio_mkfile(const char *name, const char *location,
>  		goto error;
>  	}
>  
> +	if (buf.st_mtime > 0xffffffff) {
> +		fprintf(stderr, "%s: Timestamp exceeds maximum cpio timestamp, clipping.\n",
> +			location);
> +		buf.st_mtime = 0xffffffff;
> +	}
> +
>  	filebuf = malloc(buf.st_size);
>  	if (!filebuf) {
>  		fprintf (stderr, "out of memory\n");
> @@ -551,6 +557,17 @@ int main (int argc, char *argv[])
>  		}
>  	}
>  
> +	/*
> +	 * Timestamps after 2106-02-07 06:28:15 UTC have an ascii hex time_t
> +	 * representation that exceeds 8 chars and breaks the cpio header
> +	 * specification.
> +	 */
> +	if (default_mtime > 0xffffffff) {
> +		fprintf(stderr, "ERROR: Timestamp 0x%08x too large for cpio format\n",

"0x%08x" is at least missing an 'l'.  Possibly, showing the invalid 
timestamp does not make much sense.  If someone feeds the string 
"1607420928" into KBUILD_BUILD_TIMESTAMP, as written in the commit 
message, $(date -d $KBUILD_BUILD_TIMESTAMP +%s) returns a value that 
will probably not be helpful.

Sorry for the noise; v3 follows.

> +			default_mtime);
> +		exit(1);
> +	}
> +
>  	if (argc - optind != 1) {
>  		usage(argv[0]);
>  		exit(1);
> -- 
> 2.30.1

-- 
epost|xmpp: nicolas@...sle.eu          irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
     -- frykten for herren er opphav til kunnskap --