Message-ID: <Zskp364_oYM4T8BQ@pollux>
Date: Sat, 24 Aug 2024 02:31:27 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Jann Horn <jannh@...gle.com>
Cc: Luis Chamberlain <mcgrof@...nel.org>,
	Russ Weight <russ.weight@...ux.dev>,
	Danilo Krummrich <dakr@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2] firmware_loader: Block path traversal

On Fri, Aug 23, 2024 at 08:38:55PM +0200, Jann Horn wrote:
> Most firmware names are hardcoded strings, or are constructed from fairly
> constrained format strings where the dynamic parts are just some hex
> numbers or such.
> 
> However, there are a couple codepaths in the kernel where firmware file
> names contain string components that are passed through from a device or
> semi-privileged userspace; the ones I could find (not counting interfaces
> that require root privileges) are:
> 
>  - lpfc_sli4_request_firmware_update() seems to construct the firmware
>    filename from "ModelName", a string that was previously parsed out of
>    some descriptor ("Vital Product Data") in lpfc_fill_vpd()
>  - nfp_net_fw_find() seems to construct a firmware filename from a model
>    name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I
>    think parses some descriptor that was read from the device.
>    (But this case likely isn't exploitable because the format string looks
>    like "netronome/nic_%s", and there shouldn't be any *folders* starting
>    with "netronome/nic_". The previous case was different because there,
>    the "%s" is *at the start* of the format string.)
>  - module_flash_fw_schedule() is reachable from the
>    ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as
>    GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is
>    enough to pass the privilege check), and takes a userspace-provided
>    firmware name.
>    (But I think to reach this case, you need to have CAP_NET_ADMIN over a
>    network namespace that a special kind of ethernet device is mapped into,
>    so I think this is not a viable attack path in practice.)
> 
> Fix it by rejecting any firmware names containing ".." path components.
> 
> For what it's worth, I went looking and haven't found any USB device
> drivers that use the firmware loader dangerously.
> 
> Cc: stable@...r.kernel.org
> Fixes: abb139e75c2c ("firmware: teach the kernel to load firmware files directly from the filesystem")
> Signed-off-by: Jann Horn <jannh@...gle.com>
> ---
> Changes in v2:
> - describe fix in commit message (dakr)
> - write check more clearly and with comment in separate helper (dakr)
> - document new restriction in comment above request_firmware() (dakr)
> - warn when new restriction is triggered
> - Link to v1: https://lore.kernel.org/r/20240820-firmware-traversal-v1-1-8699ffaa9276@google.com
> ---
>  drivers/base/firmware_loader/main.c | 41 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
> index a03ee4b11134..dd47ce9a761f 100644
> --- a/drivers/base/firmware_loader/main.c
> +++ b/drivers/base/firmware_loader/main.c
> @@ -849,6 +849,37 @@ static void fw_log_firmware_info(const struct firmware *fw, const char *name,
>  {}
>  #endif
>  
> +/*
> + * Reject firmware file names with ".." path components.
> + * There are drivers that construct firmware file names from device-supplied
> + * strings, and we don't want some device to be able to tell us "I would like to
> + * be sent my firmware from ../../../etc/shadow, please".
> + *
> + * Search for ".." surrounded by either '/' or start/end of string.
> + *
> + * This intentionally only looks at the firmware name, not at the firmware base
> + * directory or at symlink contents.
> + */
> +static bool name_contains_dotdot(const char *name)
> +{
> +	size_t name_len = strlen(name);
> +	size_t i;
> +
> +	if (name_len < 2)
> +		return false;
> +	for (i = 0; i < name_len - 1; i++) {
> +		/* do we see a ".." sequence? */
> +		if (name[i] != '.' || name[i+1] != '.')
> +			continue;
> +
> +		/* is it a path component? */
> +		if ((i == 0 || name[i-1] == '/') &&
> +		    (i == name_len - 2 || name[i+2] == '/'))
> +			return true;
> +	}
> +	return false;
> +}

Why do you open code it, instead of using strstr() and strncmp() like you did
in v1? I think your approach from v1 read way better.

> +
>  /* called from request_firmware() and request_firmware_work_func() */
>  static int
>  _request_firmware(const struct firmware **firmware_p, const char *name,
> @@ -869,6 +900,14 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
>  		goto out;
>  	}
>  
> +	if (name_contains_dotdot(name)) {
> +		dev_warn(device,
> +			 "Firmware load for '%s' refused, path contains '..' component",
> +			 name);
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
>  	ret = _request_firmware_prepare(&fw, name, device, buf, size,
>  					offset, opt_flags);
>  	if (ret <= 0) /* error or already assigned */
> @@ -946,6 +985,8 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
>   *      @name will be used as $FIRMWARE in the uevent environment and
>   *      should be distinctive enough not to be confused with any other
>   *      firmware image for this or any other device.
> + *	It must not contain any ".." path components - "foo/bar..bin" is
> + *	allowed, but "foo/../bar.bin" is not.
>   *
>   *	Caller must hold the reference count of @device.
>   *
> 
> ---
> base-commit: b0da640826ba3b6506b4996a6b23a429235e6923
> change-id: 20240820-firmware-traversal-6df8501b0fe4
> -- 
> Jann Horn <jannh@...gle.com>
> 

Powered by blists - more mailing lists