Re: Possible security hole? [was: verify_area(...) possible problem]

Pavel Machek (pavel@bug.ucw.cz)
Sat, 17 Apr 1999 22:37:09 +0200

> Andi Kleen wrote:
> > In theory not, because early i386 with broken supervisor write
> > protection checking depend on on verify_area/access_ok to actually
> > check the page tables. The page tables could change while you sleep.
> >
> > But, the concept is really broken, because e.g. when a user access
> > crosses two vm areas, and the user access faults (=sleeps) in the
> > first, and the goes on to write to the second, while that has been
> > already unmapped by another thread, it overwrites innoncent
> > memory.
>
> Andi, nice thinking.
>
> Can this (the current behaviour) be a security hole?
> I'm thinking that two cloned threads could, on an i386 with the
> broken WP protection:
>
> (a) read a file to hack to bring it into cache, e.g. /bin/su
> (b) does a shared writable mapping of some writable file that is not in cache
> (use your imagination)
> (c) thread #2 spins checking a flag
> (d) thread #1 writes the flag and then writes to the writable mapping
> (e) thread #1 blocks to pull in the page
> (f) thread #2 sees the flag and maps /bin/su into place (read only)
> (g) the page comes in though the mapping is no longer present
> (h) thread #1 unblocks and overwrites a page of /bin/su
> (i) run /bin/su, get root with no password check, H940R D00D2 R001
> --> there isn't even any evidence on disk
>
> This will not happen if, when thread #1 blocks, the remapping is blocked
> by a lock. But I'm not sure, is it? I don't have an i386 to try it on.

This is old news. I even did a patch: [hopefully noone uses 386's for
multiuser shell servers :-)] . But still it is a bug. I think it
should be fixed.

I do have 386. If you post me nice .c program, I'll happily test it
for you. [What about duplicating it by forcing kernel to think it has
old 386. That should work - 486+ all backward compatible after all.]

Linus, would you mind closing this security hole?

Pavel

--- clean//kernel/fork.c Sat Apr 17 22:32:00 1999
+++ linux/kernel/fork.c Sat Apr 17 19:03:07 1999
@@ -513,6 +513,7 @@
return 0;
}

+#ifdef CONFIG_M386
+int unsafe_clone = 0;
+#endif
+
static inline void copy_flags(unsigned long clone_flags, struct task_struct *p)
{
unsigned long new_flags = p->flags;
@@ -540,9 +544,27 @@

current->vfork_sem = &sem;

+#ifdef CONFIG_M386
+ if ( (!unsafe_clone) && (clone_flags & CLONE_VM) && (!boot_cpu_data.wp_works_ok) && (!suser())) {
+ /* On 80386 (486+ is safe), it is not-really-safe to have
+ * two threads sharing address space. Malicious user could
+ * use it to do something bad.
+ * <pavel@atrey.karlin.mff.cuni.cz>
+ */
+ static int complained = 0;
+ if (!complained) {
+ printk( KERN_INFO "clone disabled - unsecure (echo 1 >/proc/sys/kernel/unsafe-clone to enable).\n" );
+ complained++;
+ }
+ return -ENOSYS;
+ }
+#endif
p = alloc_task_struct();
if (!p)
goto fork_out;

*p = *current;

--- clean//kernel/sysctl.c Fri Feb 26 18:40:04 1999
+++ linux/kernel/sysctl.c Fri Feb 26 11:49:52 1999
@@ -37,7 +37,9 @@
extern char binfmt_java_interpreter[], binfmt_java_appletviewer[];
extern int sysctl_overcommit_memory;
extern int nr_queued_signals, max_queued_signals;
-
+#ifdef CONFIG_M386
+extern int unsafe_clone;
+#endif
#ifdef CONFIG_KMOD
extern char modprobe_path[];
#endif
@@ -174,10 +180,14 @@
{KERN_JAVA_APPLETVIEWER, "java-appletviewer", binfmt_java_appletviewer,
64, 0644, NULL, &proc_dostring, &sysctl_string },
#endif
+#ifdef CONFIG_M386
+ {KERN_UNSAFE_CLONE, "unsafe-clone", &unsafe_clone, sizeof(int),
+ 0644, NULL, &proc_dointvec},
+#endif
#ifdef __sparc__
{KERN_SPARC_REBOOT, "reboot-cmd", reboot_command,
256, 0644, NULL, &proc_dostring, &sysctl_string },
#endif
#ifdef __powerpc__
{KERN_PPC_HTABRECLAIM, "htab-reclaim", &htab_reclaim_on, sizeof(int),
0644, NULL, &proc_dointvec},

-- 
I'm really pavel@atrey.karlin.mff.cuni.cz. 	   Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/