Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.sysv386 Subject: Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386 Message-ID: Date: 17 Feb 91 21:04:49 GMT References: <6027@unix386.Convergent.COM> <1991Feb15.134715.16979@virtech.uucp> <54663@bigtex.cactus.org> <1991Feb16.214824.2790@kithrup.COM> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 43 Nntp-Posting-Host: odin In-reply-to: sef@kithrup.COM's message of 16 Feb 91 21:48:24 GMT On 16 Feb 91 21:48:24 GMT, sef@kithrup.COM (Sean Eric Fagan) said: sef> Once again: the '387 emulator [ ... ] needs to keep the fp sef> registers somewhere, and they are very much process-related, the sef> "proper" place to keep them is in the u area, just like other sef> registers. In my profound naivety :-) I'd have put them at the top of the user stack, in the user portion of the address space. The last place in the world where I'd have put them would be in the u-area. This may need some small difference in actions between the case where you actually have a 387 (then the kernel saves the state of the 387 in *its* data segment, the u-area) and the case where you have an emulator (then the emulator, that is in effect a user mode shared library, saves the state of the 387 in the user mode data segment, e.g. the stack). sef> Since the emulator needs to be able to write to the registers in sef> the u area, your process can *also* write to the registers in the u sef> area. [ ... ] sef> The bug is not in the emulator, and having sources won't fix the sef> problem. The "bug" is in the entire way it's set up, and, to fix sef> it, you need to rearrange lots of things. (Well, actually, just sef> move some things around.) The decision of making the u-area writable is so absurd that it cannot be possibly have been just because of sloppiness; this seem confirmed by the decision to keep it like this even after reports that others had found this trapdoor that makes the Unix kernel itself into a trojan horse. Follow the logic: Some honest guy has found the trojan horse trapdoor and reported it to the suppleir and then to the net: how many less honest people have found it and kept it to themselves? If you make a program into a trojan horse, you expect people that find the trapdoor to collude with you and keep it secret, especially when you tell them to hush it, as you hope that they understand that it is not in their self interest to let everybody else know about it. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk