Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!sixhub!davidsen From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr) Newsgroups: comp.unix.sysv386 Subject: Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386 Keywords: BAD BUG Message-ID: <3227@sixhub.UUCP> Date: 18 Feb 91 15:05:16 GMT References: <329@alderan.uucp> <3215@sixhub.UUCP> <1991Feb18.042427.9434@kithrup.COM> Reply-To: davidsen@sixhub.UUCP (bill davidsen) Organization: *IX Public Access UNIX, Schenectady NY Lines: 38 In article <1991Feb18.042427.9434@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: | Bill, the bug is *not* in the emulator. It's in the way the entire system | (kernel and emulator) were designed. I posted a longish article going into | this in a bit of detail. My understanding is that the emulator is keeping the fake registers in the user area, and mapping that into addressable user space. By mapping the fake registers elsewhere, such as the suggestion of high stack, the user area would not be in the user process address space. There's no good reason to store the emulated registers in the user area, just because that's where they go for the hardware registers. Other system services map small sieces of memory, such as shared memory allocation. There's no justification for having the user area mapped when all that's needed is a section of memory large enough to hold the emulated FPU stack and registers. The saved pseudo registers could be in a separate segment, but I don't see any requirement to get then out of user default space, it's just an implementation detail. I willing to be shown that the error lies elsewhere, but that sounds like a pure error in the emulation to me. The fix may require a new emulator which uses another part of memory, but the need for and major kernel changes is not intuitively obvious (to me). The code to attach the emulator is presumably there already, and the code to map the uaer block can just be flat out disabled. Again, I may be missing something, but the solution seems pretty simple. Disable the mapping of the user block into user space, then have the emulator allocate memory, use high stack, or otherwise look in a more sensible place. I'd bet that there's one pointer to the user block structure, and that changing the logic which initializes it would suffice. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me