Date: Tue, 26 Feb 2013 13:31:59 -0700 From: Kurt Seifried <kseifried@...hat.com> To: oss-security@...ts.openwall.com CC: Greg KH <greg@...ah.com> Subject: Re: CVE request - Linux kernel: VFAT slab-based buffer overflow -----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-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ