Date: Sun, 18 May 2003 04:13:16 +0100 From: "Killing" <killing@barrysworld.com> To: "Killing" <killing@barrysworld.com>, "Robert Watson" <rwatson@freebsd.org>, "Poul-Henning Kamp" <phk@phk.freebsd.dk>, <jnweiger@immd4.informatik.uni-erlangen.de>, <mlschroe@immd4.informatik.uni-erlangen.de> Cc: freebsd-security@freebsd.org Subject: Re: open and euid security flaw in 5.0-Current? Message-ID: <000501c31ceb$6f3d5a90$9f00a8c0@mshome.net> References: <6557.1053197031@critter.freebsd.dk> <012201c31cda$b9dafa50$9f00a8c0@mshome.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok I figgered out the problem here with screen. Whats happening is when userA does su - userB -c "screen -r <screenid>" screen checks the permissions on /dev/ttyX to ensure that it has permission on it which of course with the new impementation it does. What happens next is it tells the running screen process to attach to /dev/ttyX but this is euid and ruid userB unlike the testing screen process which was euid userB but ruid userA. So when the running screen process gets the message to attach to /dev/ttyX it doesnt have permission to do so and hence fails. From a screen point of view I see two ways to avoid this: 1. set ruid / rgid = euid / rgid this may have other implications as the current code for this check does: xseteuid(real_uid); xsetegid(real_gid); fi = fopen(name, mode); xseteuid(eff_uid); xsetegid(eff_gid); 2. change the way screen notifies the other process to connect to a tty so it can have feedback of the success or failure. Im not sure I like either so I suppose the question is: Is there a way to check access to the tty without setting ruid = euid? For a hack the current patch to screen seems to do the trick but Im unsure of the full impications to this if Juergen or Michael could comment it would be appreciated. *** os.h Sun May 18 03:08:38 2003 --- os.h.orig Sun May 18 03:10:18 2003 *************** *** 163,169 **** #if defined(HAVE_SETEUID) || defined(HAVE_SETREUID) ! # if defined(__FreeBSD__) && __FreeBSD_version < 500113 || !defined(__FreeBSD__) ! # define USE_SETEUID ! # endif #endif --- 163,167 ---- #if defined(HAVE_SETEUID) || defined(HAVE_SETREUID) ! # define USE_SETEUID #endif ----- Original Message ----- From: "Killing" <killing@barrysworld.com> To: "Robert Watson" <rwatson@freebsd.org>; "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: <freebsd-hackers@freebsd.org>; <freebsd-security@freebsd.org> Sent: Sunday, May 18, 2003 2:13 AM Subject: Re: open and euid security flaw in 5.0-Current? > I'll look at screen more carfully, hopefully on monday evening. As what > its doing atm is succeding its access checks for the controlling terminal > but then failing to actually reattach. I agree that there really should be > no need for the wrapper I have which traps the screen tty dev access > error and acts on it. > > Thanks for all the feedback guys. > > Steve > ----- Original Message ----- > From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> > To: "Robert Watson" <rwatson@freebsd.org> > Cc: "Killing" <killing@barrysworld.com>; <freebsd-hackers@freebsd.org>; > <freebsd-security@freebsd.org> > Sent: Saturday, May 17, 2003 7:43 PM > Subject: Re: open and euid security flaw in 5.0-Current? > > > > In message <Pine.NEB.3.96L.1030517102700.42953A-100000@fledge.watson.org>, > Robe > > rt Watson writes: > > > > > >On Sat, 17 May 2003, Killing wrote: > > > > > >> Thanks for that Robert will do some more investigation as it does break > > >> screen :( > > > > > >Try replacing the devfs_access() contents with solely a call to: > > > > > > return (vaccess(vp->v_type, de->de_mode, de->de_uid, de->de_gid, > > > ap->a_mode ,ap->a_cred, NULL)); > > > > > >This should restore the traditional access controls for the controlling > > >terminal. Again, I'm not sure what the rationale is for the new access > > >controls, and want to find out before we make any changes to the base > > >system, but it does strike me that screen breaking is gratuitous :-). > > > > This is one of those areas, where the hackish way (ie: /dev/tty) > > which something were implemented, leaves us with the problem of > > guessing what the underlying intent actually was/is. > > > > It used to be that /dev/tty had its own pseudo device driver, which > > would do weird stunts to act on the applicable real tty device driver > > for the controlling terminal of the current process. > > > > The resulting semantics of this is that a process can always open its > > controlling terminal, by opening "/dev/tty", but inconsistently, is > > not guaranteed to be able open it by name: > > > > ssh machine -l user1 > > ... > > user1% date > /dev/tty # works > > user1% date > `tty` # works > > user1% ls -l `tty` > > crw--w---- 1 user1 tty 5, 1 May 17 20:24 /dev/ttyp1 > > user1% su - user2 > > user2% date > /dev/tty # works > > user2% date > `tty` # doesn't work. > > > > The change I did, was to use the "on demand device creation" feature > > of DEVFS, to make /dev/tty a sort of "variant symlink" to the current > > process' controlling terminal device, and thereby getting rid of a > > lot of hackish code, which amongst other things, complicated locking. > > > > critter phk> ls -l /dev/tty `tty` > > crw--w---- 1 phk tty 5, 3 May 17 20:40 /dev/tty > > crw--w---- 1 phk tty 5, 3 May 17 20:40 /dev/ttyp3 > > > > This means that VOP_OPEN checked against the _real_ permissions of > > the tty breaking the the following scenario: > > > > ssh machine -l user1 > > ... > > user1% ls -l `tty` > > crw--w---- 1 user1 tty 5, 1 May 17 20:24 /dev/ttyp1 > > user1% su - user2 > > # user2 has no access to /dev/ttyp1, so /dev/tty cannot > > # be opened. > > > > Therefore, the access check was changed to always allowing the > > controlling terminal to be opened resulting in the following > > much simpler semantics: > > > > % date > /dev/tty # always works. > > % date > `tty` # always works. > > > > This IMO, reflects the intentions of the original /dev/tty, and > > since it is simpler and contains no exceptions, I also think it > > correctly reflects the "UNIX[*] philosophy" much better than > > the previous behaviour. > > > > I have no idea why or what screen(1) is doing, but from your > > description it seems to rely on the undocumented fact that in certain > > specific situations > > user2% date > `/dev/tty' > > would fail. > > > > In my eyes, that is a clear bug in screen(1). > > > > Poul-Henning > > > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by > incompetence. > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000501c31ceb$6f3d5a90$9f00a8c0>