[ Search ] [ What's New? ] [ About ]
[ Bugs ] [ Misc ] [ Mailing Lists ] [ Newgroups ] [ NewsWire ] [ Papers ] [ People ]
[ Pictures ] [ Publications ] [ Responce Teams ] [ Tools ] [ Upcoming Events ] [ Web Sites ]

/dev/null
Systems Affected:Microport Unix 3.0e and probably other versions of Microport Unix.
Problem: Any user can execute '386 I/O instructions in Microport's Unix 3.0e. The bug is as fallows: the /dev/mem driver was given an ioctl to do I/O instructions. (Examination of the source suggests that this was done by Microport, in the modification, no check on the minor device number is made. Since /dev/null uses the same driver, ioctls on /dev/null can also do I/O instructions. To makeuse of the bug, one constructs a program to open /dev/null and do ioctls. This does not require access to a compiler; shell access and any of a number of tools are sufficient. Taking advantage of this bug permits any number of security problems: easiest is to crash the system. A clever hacker can almost certainly arrange to get a uid 0 process with it. (Think about DMA'ing a zero into just the right byte of the process table.)
Solution: This is a kernel bug and there is no easy work-around for binary only sites. The following should eliminate the bug, with some side effects:

	adb -w /unix
	mmioctl?W0c3
*All* memory driver ioctls will be ignored with this patch. Programs that us the memory driver to do I/O instructions will fail. Also, there is reboot code in there which has been superceded by the uadmin system call; I don't think anything uses that. The biggest problem is that this same ioctl us used for the limited runtime control; I have no idea whether your system will boot with this patch, /etc/init may well have a hissy fit when it tries to do those ioctls. If you have source code, add 

	if(minor(dev) == 2) {
		u.u_error = ENXIO;
		return;
	}
to the top of mmioctl in mem.c. This will eliminate the bug.

Aleph One / aleph1@underground.org
Copyright © 1996 Computer Underground Society. All rights reserved.