[PATCH] ubi: avoid workqueue format string leak

[PATCH] ubi: avoid workqueue format string leak

[Kees Cook]

When building the name for the workqueue thread, make sure a format
string cannot leak in from the disk name.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/mtd/ubi/block.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
index 7ff473c871a9..8d659e6a1b4c 100644
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -431,7 +431,7 @@ int ubiblock_create(struct ubi_volume_info *vi)
 	 * Create one workqueue per volume (per registered block device).
 	 * Rembember workqueues are cheap, they're not threads.
 	 */
-	dev->wq = alloc_workqueue(gd->disk_name, 0, 0);
+	dev->wq = alloc_workqueue("%s", 0, 0, gd->disk_name);
 	if (!dev->wq)
 		goto out_free_queue;
 	INIT_WORK(&dev->work, ubiblock_do_work);
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

Re: [PATCH] ubi: avoid workqueue format string leak

[Artem Bityutskiy]

On Mon, 2014-04-07 at 21:44 -0700, Kees Cook wrote:
> When building the name for the workqueue thread, make sure a format
> string cannot leak in from the disk name.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>

Pushed to linux-ubifs / master, thanks!

-- 
Best Regards,
Artem Bityutskiy

Re: [PATCH] ubi: avoid workqueue format string leak

[Ezequiel Garcia]

Hello Kees,

Thanks for the patch.

On Apr 07, Kees Cook wrote:
> When building the name for the workqueue thread, make sure a format
> string cannot leak in from the disk name.
> 

Could you enlighten me and explain why you want to avoid the name leak?
Is it a security concern?

I'd like to understad this better, so I can avoid making such mistakes
in the future.

Thanks,
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH] ubi: avoid workqueue format string leak

[Artem Bityutskiy]

On Tue, 2014-04-08 at 10:57 -0300, Ezequiel Garcia wrote:
> Hello Kees,
> 
> Thanks for the patch.
> 
> On Apr 07, Kees Cook wrote:
> > When building the name for the workqueue thread, make sure a format
> > string cannot leak in from the disk name.
> > 
> 
> Could you enlighten me and explain why you want to avoid the name leak?
> Is it a security concern?
> 
> I'd like to understad this better, so I can avoid making such mistakes
> in the future.

Well, the basics seem to be simple, attacker makes sure gd->disk_name
contains a bunch of "%s" and other placeholders, and this leads
"workqueue_alloc()" to read kernel memory and form the workqueue name.

I did not think it through further, though, but that was enough for me
to apply the patch right away. But yeah, curios parts are:

1. How attacker could end up with a crafted "gd->disk_name"
2. How attacker gets the workqueue name then, I guess there is a sysfs
file or something, but I do not know off the top of my head.

Yeah, I am interested to get educated on this a too.

-- 
Best Regards,
Artem Bityutskiy

Re: [PATCH] ubi: avoid workqueue format string leak

[Kees Cook]

On Tue, Apr 8, 2014 at 7:43 AM, Artem Bityutskiy
<artem.bityutskiy@linux.intel.com> wrote:
> On Tue, 2014-04-08 at 10:57 -0300, Ezequiel Garcia wrote:
>> Hello Kees,
>>
>> Thanks for the patch.
>>
>> On Apr 07, Kees Cook wrote:
>> > When building the name for the workqueue thread, make sure a format
>> > string cannot leak in from the disk name.
>> >
>>
>> Could you enlighten me and explain why you want to avoid the name leak?
>> Is it a security concern?
>>
>> I'd like to understad this better, so I can avoid making such mistakes
>> in the future.
>
> Well, the basics seem to be simple, attacker makes sure gd->disk_name
> contains a bunch of "%s" and other placeholders, and this leads
> "workqueue_alloc()" to read kernel memory and form the workqueue name.

Right. I don't think there is an actual exploitable vulnerability
here, but it's a best-practice to not pass variable strings in as a
potential format string.

> I did not think it through further, though, but that was enough for me
> to apply the patch right away. But yeah, curios parts are:
>
> 1. How attacker could end up with a crafted "gd->disk_name"

At present, the only way I know how to set that is via some special
controls in md, but I assume that would not work via ubi.

> 2. How attacker gets the workqueue name then, I guess there is a sysfs
> file or something, but I do not know off the top of my head.

This I haven't checked, but if there isn't a way to do it now, we can
at least avoid a nasty surprise in the future if one is created. :)

> Yeah, I am interested to get educated on this a too.

Thanks for pulling the fix!

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [PATCH] ubi: avoid workqueue format string leak

[Ezequiel Garcia]

On Apr 08, Kees Cook wrote:
> On Tue, Apr 8, 2014 at 7:43 AM, Artem Bityutskiy
> <artem.bityutskiy@linux.intel.com> wrote:
> > On Tue, 2014-04-08 at 10:57 -0300, Ezequiel Garcia wrote:
> >> Hello Kees,
> >>
> >> Thanks for the patch.
> >>
> >> On Apr 07, Kees Cook wrote:
> >> > When building the name for the workqueue thread, make sure a format
> >> > string cannot leak in from the disk name.
> >> >
> >>
> >> Could you enlighten me and explain why you want to avoid the name leak?
> >> Is it a security concern?
> >>
> >> I'd like to understad this better, so I can avoid making such mistakes
> >> in the future.
> >
> > Well, the basics seem to be simple, attacker makes sure gd->disk_name
> > contains a bunch of "%s" and other placeholders, and this leads
> > "workqueue_alloc()" to read kernel memory and form the workqueue name.
> 
> Right. I don't think there is an actual exploitable vulnerability
> here, but it's a best-practice to not pass variable strings in as a
> potential format string.
> 

I see, thanks for explanation. I'll certainly try to keep this in mind!

> > I did not think it through further, though, but that was enough for me
> > to apply the patch right away. But yeah, curios parts are:
> >
> > 1. How attacker could end up with a crafted "gd->disk_name"
> 
> At present, the only way I know how to set that is via some special
> controls in md, but I assume that would not work via ubi.
> 

I guess it's not possible in our case, given we are hard-setting the name
to ubiblock%d_%d:

  sprintf(gd->disk_name, "ubiblock%d_%d", dev->ubi_num, dev->vol_id);

Nevertheless the fix is valid, so thanks a lot and keep them coming!
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com