Re: [PATCH] firmware: make sure paths remain relative
On Tue, Dec 18, 2012 at 12:09 PM, Kees Cook wrote: > > Do you mean a printk should be emitted on this error path? I can add that if > so. dev_err() should be better. With that, please feel free to add Acked-by: Ming Lei Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: make sure paths remain relative
On Mon, Dec 17, 2012 at 6:15 PM, Ming Lei wrote: > On Tue, Dec 18, 2012 at 9:37 AM, Kees Cook wrote: >> On Mon, Dec 17, 2012 at 5:30 PM, Ming Lei wrote: >>> On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook wrote: Some devices have configurable firmware locations. If these configuration mechanisms are exposed to unprivileged userspace, it may be possible to >>> >>> I an wondering how the unprivileged userspace can write the firmware sysfs >>> to trigger loading firmware? >> >> If a daemon were to, for example, make firmware selectable by the user >> (which under certain situations is possible in Chrome OS), it seems >> wasteful require these userspace tools/interfaces to each perform >> filtering, so I figured it would be trivial to put in here instead to >> avoid possible future vulnerabilities. > > OK, I understand your concern, and looks reasonable wrt. the specific > problem, and IMO, it is better to provide failure log so that the affected > device driver can be fixed easily. Do you mean a printk should be emitted on this error path? I can add that if so. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: make sure paths remain relative
On Tue, Dec 18, 2012 at 9:37 AM, Kees Cook wrote: > On Mon, Dec 17, 2012 at 5:30 PM, Ming Lei wrote: >> On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook wrote: >>> Some devices have configurable firmware locations. If these configuration >>> mechanisms are exposed to unprivileged userspace, it may be possible to >> >> I an wondering how the unprivileged userspace can write the firmware sysfs >> to trigger loading firmware? > > If a daemon were to, for example, make firmware selectable by the user > (which under certain situations is possible in Chrome OS), it seems > wasteful require these userspace tools/interfaces to each perform > filtering, so I figured it would be trivial to put in here instead to > avoid possible future vulnerabilities. OK, I understand your concern, and looks reasonable wrt. the specific problem, and IMO, it is better to provide failure log so that the affected device driver can be fixed easily. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: make sure paths remain relative
On Mon, Dec 17, 2012 at 5:30 PM, Ming Lei wrote: > On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook wrote: >> Some devices have configurable firmware locations. If these configuration >> mechanisms are exposed to unprivileged userspace, it may be possible to > > I an wondering how the unprivileged userspace can write the firmware sysfs > to trigger loading firmware? If a daemon were to, for example, make firmware selectable by the user (which under certain situations is possible in Chrome OS), it seems wasteful require these userspace tools/interfaces to each perform filtering, so I figured it would be trivial to put in here instead to avoid possible future vulnerabilities. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: make sure paths remain relative
On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook wrote: > Some devices have configurable firmware locations. If these configuration > mechanisms are exposed to unprivileged userspace, it may be possible to I an wondering how the unprivileged userspace can write the firmware sysfs to trigger loading firmware? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] firmware: make sure paths remain relative
Some devices have configurable firmware locations. If these configuration
mechanisms are exposed to unprivileged userspace, it may be possible to
load firmware from an unexpected location. To minimize the risk of this,
make sure the string "../" does not appear in the firmware name. This
means that neither the users of request_firmware, nor the uevent handler
have to do this filtering themselves.
Signed-off-by: Kees Cook
---
drivers/base/firmware_class.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index d814603..9c4fb1c 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -814,6 +814,9 @@ _request_firmware_prepare(const struct firmware
**firmware_p, const char *name,
if (!firmware_p)
return ERR_PTR(-EINVAL);
+ if (strstr(name, "../"))
+ return ERR_PTR(-EINVAL);
+
*firmware_p = firmware = kzalloc(sizeof(*firmware), GFP_KERNEL);
if (!firmware) {
dev_err(device, "%s: kmalloc(struct firmware) failed\n",
--
1.7.9.5
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
