Re: CVE request - Linux kernel: VFAT slab-based buffer overflow

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/26/2013 11:16 AM, Greg KH wrote:
> On Tue, Feb 26, 2013 at 11:56:02AM -0600, Joshua J. Drake wrote:
> > All,
> >
> > I'd like to request a CVE for an issue leading to a buffer
> > overflow of a slab allocated buffer in the VFAT file system code.
> > The issue manifests when converting UTF8 characters to UTF16
> > inside the "utf8s_to_utf16s" function. Reaching this code
> > requires writing to a VFAT partition that has been mounted with
> > the "utf8" option. Ubuntu 10.04 mounts USB sticks with this
> > option by default. Most Android devices mount eMMC/SD cards/etc
> > with this option.
> >
> > The issue affects kernels prior to 3.2. Many Android devices
> > remain affected today.
> >
> > I'm not entirely sure when the issue was introduced at this
> > moment. It appears to have been introduced here: 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=74675a58507e769beee7d949dbed788af3c4139d
The issue was fixed here:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0720a06a7518c9d0c0125bd5d1f3b6264c55c3dd
The issue was partially disclosed here (this spurred my investigation):
> > http://www.exploit-db.com/exploits/23248/
> >
> > Props to G13 for finding it. It's pretty disappointing that 
> > Google/Android security teams (and of course Linux maintainers)
> > didn't responsibly disclose the issue so other Linux kernel
> > packagers could package a fix.

Please use CVE-2013-1773 for this issue.

> Ok, how could the Linux maintainers have done anything about this,
> when the developers involved in creating this patch didn't even
> realize it was a "security" issue in the first place?
>
> I'm tired of people complaining about how the Linux kernel
> developers handle security issues, when no one seems to have a
> suggestion as to how anything could actually be done better.
>
> And note, I was one of the people involved in this patch, and I
> didn't notice anything special about it, so if you want to blame
> anyone, blame me for not tagging it for inclusion in the stable
> kernel releases.
>
> greg k-h

I suspect part of the problem is scale. Most people don't understand
the scale at which the Linux Kernel and vendors handle bug fixes and
code changes. External people simply see a few poorly handled security
related issues and probably think "well how hard can it be to properly
a few extra security flaws?" but they don't see that those 5 security
issues were buried in 10,000 other code fixes. The resources needed to
audit every code change for a security impact simply aren't available
(and even if we had enough talented people who exactly is going to pay
them all?).

While things are not perfect (and likely never will be) I think they
are pretty good overall considering how much code and code change the
Linux Kernel handles.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJRLRu/AAoJEBYNRVNeJnmTbZsP/RWINtKLJwZW4iQwiNC6ax6W
vgdLP1xmcwytVXn+z7NasD2z7Q+25hYLyZcQ3WjFSyUEhMusBMlpuw7wy2w8lK7d
JwgvXCES+qfgmUyn9DQwOCxnF0V71AjLhxlFRXMzlcD1zXbk1urXzaxgLW58Wltt
d7WnpwolcMRj6iRVVe6RKIKKqg5UVJEtcVwWMyq0IFkLq6lEvFQ0/ABZv++HSZ4v
LmChrvfqX+gesZ8+uMhI707eXq1T0m3AZHUyNIjGVPwDpv3Gy3DY2ARD49nAONpl
aw+4FH8NdN906IuzzpVMOiB0Xdc/PfcdwZSEbk+tPwdcnc1a9fG75cGL+A5yusVT
UfaocKhFkBVAv4LK5lSBZwTi24UMa1QXkosEGzrB5aw22dfmbgbFGkVJlcd9Zg6g
1fq9ZtS5PmsGjKpqIr8/2CfJLFWHTw4wQoRQb5LbfZeoM5bfmOYhVNFSBnJxDzEz
79QtHv0f1GKnas9jUKO6RN4ULfBghv30fBtEEQ2aGyH/AR2BQXm8JJFsx2d+FhZi
9SI66s+vESJqAgGu4oBNrKwwH6yyRAp36g9M4wwVV5dHYtbQQTMMfmjZhmpbt90P
cujU4WMEHXAKiU9vuxsErmhHBPvmgtUAYuEJo7cMpeVL5fLCn//yrzIx2QgJxwfW
tyQMZRl3tMeUTBD03CL3
=SQJ7
-----END PGP SIGNATURE-----