From: Ryan Mallon <rmallon@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>,
linux@horizon.com, Jiri Kosina <jkosina@suse.cz>,
eldad@fogrefinery.com, Andrew Morton <akpm@linux-foundation.org>,
Dan Rosenberg <dan.j.rosenberg@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH] printk: Check real user/group id for %pK
Date: Mon, 30 Sep 2013 08:35:35 +1000 [thread overview]
Message-ID: <5248AB37.7000100@gmail.com> (raw)
Some setuid binaries will allow reading of files which have read permission by the real user id. This is problematic with files which use %pK because the contents of the file is different when opened as root, and displaying the contents may leak kernel pointer values.
This happens for example with the setuid pppd application on Ubuntu 12.04:
$ head -1 /proc/kallsyms
00000000 T startup_32
$ pppd file /proc/kallsyms
pppd: In file /proc/kallsyms: unrecognized option 'c1000000'
This will only leak the pointer value from the first line, but other setuid binaries may leak more information.
Fix this by adding a check that in addition to the current process having CAP_SYSLOG, that effective user and group ids are equal to the real ids. If a setuid binary reads the contents of a file which uses %pK then the pointer values will be printed as NULL if the real user is unprivileged.
Signed-off-by: Ryan Mallon <rmallon@gmail.com>
---
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 26559bd..b1cd14d 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1312,10 +1312,24 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
spec.field_width = default_width;
return string(buf, end, "pK-error", spec);
}
- if (!((kptr_restrict == 0) ||
- (kptr_restrict == 1 &&
- has_capability_noaudit(current, CAP_SYSLOG))))
- ptr = NULL;
+
+ /*
+ * If kptr_restrict is set to 2, then %pK always prints as
+ * NULL. If it is set to 1, then only print the real pointer
+ * value if the current proccess has CAP_SYSLOG and is running
+ * with the same credentials it started with. We don't want
+ * badly written setuid binaries being able to read the real
+ * pointers on behalf of unprivileged users.
+ */
+ {
+ const struct cred *cred = current_cred();
+
+ if (kptr_restrict == 2 || (kptr_restrict == 1 &&
+ (!has_capability_noaudit(current, CAP_SYSLOG) ||
+ !uid_eq(cred->euid, cred->uid) ||
+ !gid_eq(cred->egid, cred->gid))))
+ ptr = NULL;
+ }
break;
case 'N':
switch (fmt[1]) {
next reply other threads:[~2013-09-29 22:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-29 22:35 Ryan Mallon [this message]
2013-09-29 23:15 ` [PATCH] printk: Check real user/group id for %pK George Spelvin
2013-09-29 23:26 ` Ryan Mallon
2013-09-29 23:41 ` George Spelvin
2013-09-30 0:41 ` Dan Rosenberg
2013-09-30 0:56 ` Ryan Mallon
2013-09-30 0:59 ` Dan Rosenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5248AB37.7000100@gmail.com \
--to=rmallon@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.rosenberg@gmail.com \
--cc=eldad@fogrefinery.com \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox