* [PATCH] firmware: make sure paths remain relative
@ 2012-12-14 22:51 Kees Cook
2012-12-18 1:30 ` Ming Lei
0 siblings, 1 reply; 6+ messages in thread
From: Kees Cook @ 2012-12-14 22:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Ming Lei, Greg Kroah-Hartman
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 <keescook@chromium.org>
---
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
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] firmware: make sure paths remain relative
2012-12-14 22:51 [PATCH] firmware: make sure paths remain relative Kees Cook
@ 2012-12-18 1:30 ` Ming Lei
2012-12-18 1:37 ` Kees Cook
0 siblings, 1 reply; 6+ messages in thread
From: Ming Lei @ 2012-12-18 1:30 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-kernel, Greg Kroah-Hartman
On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook <keescook@chromium.org> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] firmware: make sure paths remain relative
2012-12-18 1:30 ` Ming Lei
@ 2012-12-18 1:37 ` Kees Cook
2012-12-18 2:15 ` Ming Lei
0 siblings, 1 reply; 6+ messages in thread
From: Kees Cook @ 2012-12-18 1:37 UTC (permalink / raw)
To: Ming Lei; +Cc: linux-kernel, Greg Kroah-Hartman
On Mon, Dec 17, 2012 at 5:30 PM, Ming Lei <ming.lei@canonical.com> wrote:
> On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook <keescook@chromium.org> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] firmware: make sure paths remain relative
2012-12-18 1:37 ` Kees Cook
@ 2012-12-18 2:15 ` Ming Lei
2012-12-18 4:09 ` Kees Cook
0 siblings, 1 reply; 6+ messages in thread
From: Ming Lei @ 2012-12-18 2:15 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-kernel, Greg Kroah-Hartman
On Tue, Dec 18, 2012 at 9:37 AM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Dec 17, 2012 at 5:30 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook <keescook@chromium.org> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] firmware: make sure paths remain relative
2012-12-18 2:15 ` Ming Lei
@ 2012-12-18 4:09 ` Kees Cook
2012-12-18 4:31 ` Ming Lei
0 siblings, 1 reply; 6+ messages in thread
From: Kees Cook @ 2012-12-18 4:09 UTC (permalink / raw)
To: Ming Lei; +Cc: linux-kernel, Greg Kroah-Hartman
On Mon, Dec 17, 2012 at 6:15 PM, Ming Lei <ming.lei@canonical.com> wrote:
> On Tue, Dec 18, 2012 at 9:37 AM, Kees Cook <keescook@chromium.org> wrote:
>> On Mon, Dec 17, 2012 at 5:30 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>> On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook <keescook@chromium.org> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-12-18 4:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-12-14 22:51 [PATCH] firmware: make sure paths remain relative Kees Cook
2012-12-18 1:30 ` Ming Lei
2012-12-18 1:37 ` Kees Cook
2012-12-18 2:15 ` Ming Lei
2012-12-18 4:09 ` Kees Cook
2012-12-18 4:31 ` Ming Lei
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).