linux-kernel - Re: [PATCH] ubi: avoid workqueue format string leak

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Apr 2014 08:59:19 -0700
From:	Kees Cook <keescook@...omium.org>
To:	artem.bityutskiy@...ux.intel.com
Cc:	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	Linux mtd <linux-mtd@...ts.infradead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ubi: avoid workqueue format string leak

On Tue, Apr 8, 2014 at 7:43 AM, Artem Bityutskiy
<artem.bityutskiy@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/