linux-kernel - [RFC][PATCH] utsname: completely overwrite prior information

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

Message-ID: <20080912203624.GA25965@damson.getinternet.no>
Date:	Fri, 12 Sep 2008 22:36:24 +0200
From:	Vegard Nossum <vegard.nossum@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Andrew Morton <akpm@...ux-foundation.org>
Subject: [RFC][PATCH] utsname: completely overwrite prior information

>From 25c69de4760e20cf7562cf92a55b65a71546093e Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@...il.com>
Date: Thu, 11 Sep 2008 19:59:50 +0200
Subject: [PATCH] utsname: completely overwrite prior information

On sethostname() and setdomainname(), previous information may be
retained if it was longer than than the new hostname/domainname.

This can be demonstrated trivially by calling sethostname() first
with a long name, then with a short name, and then calling uname()
to retrieve the full buffer that contains the hostname (and
possibly parts of the old hostname), one just has to look past the
terminating zero.

I don't know if we should really care that much (hence the RFC);
the only scenarios I can possibly think of is administrator
putting something sensitive in the hostname (or domain name) by
accident, and changing it back will not undo the mistake entirely,
though it's not like we can recover gracefully from "rm -rf /"
either... The other scenario is namespaces (CLONE_NEWUTS) where
some information may be unintentionally "inherited" from the
previous namespace (a program wants to hide the original name and
does clone + sethostname, but some information is still left).

I think the patch may be defended on grounds of the principle of
least surprise. But I am not adamant :-)

(I guess the question now is whether userspace should be able to
write embedded NULs into the buffer or not...)

At least the observation has been made and the patch has been
presented.

Signed-off-by: Vegard Nossum <vegard.nossum@...il.com>
---
 kernel/sys.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index 038a7bc..78b4515 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1352,7 +1352,8 @@ asmlinkage long sys_sethostname(char __user *name, int len)
 	errno = -EFAULT;
 	if (!copy_from_user(tmp, name, len)) {
 		memcpy(utsname()->nodename, tmp, len);
-		utsname()->nodename[len] = 0;
+		memset(utsname()->nodename + len, 0,
+			sizeof(utsname()->nodename) - len);
 		errno = 0;
 	}
 	up_write(&uts_sem);
@@ -1398,7 +1399,8 @@ asmlinkage long sys_setdomainname(char __user *name, int len)
 	errno = -EFAULT;
 	if (!copy_from_user(tmp, name, len)) {
 		memcpy(utsname()->domainname, tmp, len);
-		utsname()->domainname[len] = 0;
+		memset(utsname()->domainname + len, 0,
+			sizeof(utsname()->domainname) - len);
 		errno = 0;
 	}
 	up_write(&uts_sem);
-- 
1.5.5.1

--
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/