Linux Kernel strncpy() May Leak Kernel Memory to Local Processes
|
|
SecurityTracker Alert ID: 1009262
|
|
CVE Reference: CAN-2003-0465
(Links to External Site)
|
Date: Feb 29 2004
|
Impact: Disclosure of authentication information, Disclosure of system information, Disclosure of user information
|
Fix Available: Yes
Vendor Confirmed: Yes
|
Version(s): 2.4, 2.5
|
Description: A vulnerability was reported in the Linux kernel strncpy() function. A userspace application may be able to obtain very small portions of kernel memory.
In July 2003, it was reported that the Linux kernel strncpy() implementation may pad the returned buffer with portions of kernel memory on non-x86 architecutres instead of padding the buffer with NULL characters.
|
Impact: The kernel may leak small portions of kernel memory to userspace applications.
|
Solution: No solution was available at the time of the original report.
|
Vendor URL: www.kernel.org/ (Links to External Site)
|
Cause: Access control error, State error
|
Underlying OS: Linux (Caldera/SCO), Linux (Conectiva), Linux (Debian), Linux (EnGarde), Linux (Gentoo), Linux (HP Secure OS), Linux (Immunix), Linux (Mandrake), Linux (Progeny Debian), Linux (Red Hat Enterprise), Linux (Red Hat Fedora), Linux (Red Hat Linux), Linux (SGI), Linux (Slackware), Linux (Sun), Linux (SuSE), Linux (Trustix), Linux (Turbo Linux), Linux (Xandros)
|
Reported By: Alan Cox <alan@lxorguk.ukuu.org.uk>
|
Message History:
This archive entry has one or more follow-up message(s) listed below.
|
Source Message Contents
|
Date: Fri Jul 11 2003 - 16:45:37 EST
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: SECURITY - data leakage due to incorrect strncpy implementation
|
On Gwe, 2003-07-11 at 20:04, Mikulas Patocka wrote:
> What's the difference there? strlcpy always creates null-terminated
> string, strncpy doesn't. strncpy in kernel (unlike user strncpy) does not
> pad the whole destination buffer with zeros (see comment and
> implementation in lib/string.c), so I don't see any point why strncpy
> should be more secure.
Lots of kernel drivers rely on the libc definition of strncpy.
Lets update the bug report to "2.4 and 2.5 both leak arbitary kernel data
to user space" tho thankfully in small pieces. Fix required. (bcc'd to Mark to
assign a CAN number)
And for 2.4-ac I'm going to simply go make strncpy do what it says in the
book. For 2.5 the same is true and cleaner (since those who use strlcpy
properly don't take any performance hit). Actually it may make sense to
backport strlcpy for those odd performance critical ones.
I don't think its that serious a bug - the odds of getting a critical bit of
someone elses data are remarkably low but it wants fixing.
Alan
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
|
