Date: Mon, 28 Jan 2008 19:21:11 -0800 From: David Wolfskill <david@catwhisker.org> To: ports@freebsd.org Cc: danfe@freebsd.org, cperciva@freebsd.org, rafan@freebsd.org Subject: Fix for FreeBSD-SA-08:01.pty appears to break net/omnitty? Message-ID: <20080129032111.GH40423@bunrab.catwhisker.org>
next in thread | raw e-mail | index | archive | help
--Guq+xBHXhbnAFmh4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As a sysadmin, it's not unusual for me to have a desire to do similar things on sets of systems; thus, when a colleague pointed out the net/omnitty port to me, it didn't take long for me to find it useful. But I noticed on 21 January that omnitty(1) wasn't working: upon accepting the name of a host to which to connect, it appeared to "hang." Running the program under ktrace(1) showed that it did actually establish an ssh(1) connection to the target system (I used but a single one as a test case), but while omnitty didn't dispplay the result of logging in, the I/O bufffer captured by ktrace showed that the target system had responded with last login information -- for some reason, omnitty just wasn't displaying the information. Now, the system where I had first noticed the problem was my desktop at work, and I have been in the habit of tracking RELENG_6 on it on Sundays. (I track RELENG_6 on my laptop daily. I was able to reproduce the failure on the laptop, as well; I jjust hadn't noticed i, as I don't use omnitty directly from my laptop as often.) So I installed net/omnitty on my "build machine" at home, then proceeded to: * Verify that it failed (as expected) with RELENG_6 as of 21 Jan. * Verify that it worked with RELENG_6 as of 13 Jan. * Perform a "binary search" approach, narrowing down the failure case to commits made on 14 Jan in response to FreeBSD-SA-08:01.pty and FreeBSD-SA-08:02.libc: <http://docs.FreeBSD.org/cgi/mid.cgi?200801142256.m0EMuIhZ066504>. * Back out all 4 (yes, even the src/UPDATING) patches from that commit and verify that omnitty worked. * Apply the patch to src/lib/libc/stdlib/grantpt.c and verified that omnitty still worked. * Apply the patch to src/lib/libutil/pty.c and verified that omnitty now no longer worked, but "hung" (as described above). A description of the problem being addressed may be found here: <http://security.freebsd.org/advisories/FreeBSD-SA-08:01.pty.asc>. I looked in the sources for omnitty, but didn't see direct invocations of pty-related functions. Turns out that omnitty relies on devel/rote for that, and experiments with SIGABRT sent to a "hung" omnitty invocation that was built with the -g flag weren't especially informative to me -- but then, I'm not all that familiar with writing that sort of code, either. I did take a stab at adding a capability to omnitty to specify command-line arguments to ssh(1) for omnitty's "ssh" invocation -- mostly in the hope that I might be able to influence the behavior of omnitty in a positive way by (e.g.) forcing TTY allocation, or telling it to skip the X-forwarding stuff for this exercise (speeding things up a bit in the process). I didn't get around to patching the man page, but that part (the ssh flags) does appear to work, if anyone's interested. (It might be even handier to (also?) be able to grab the ssh args from an environment variable....) But I have yet to see omnitty work on a system that has rev. 1.15.20.2 of src/lib/libutil/pty.c. Anyway: it appears that rote invokes forkpty(), which invokes openpty() (which is the function implicated in FreeBSD-SA-08:01.pty). At this point... urgghh -- help? I'm a sysadmin, not a PTY-hacker. :-} I'm willing to test; I have local copies of FreeBSD CVS repositories, and I'm quite willing & able to hack & patch code, given sufficient clue or direction. One other -- somewhat related -- issue: I also track RELENG_7 and HEAD. And I set things up so I build ports under RELENG_6, then use the misc/compat6x port to be able to use these ports when running 7.x or 8.x. And I noticed something interesting: omnitty works if I run 7.x or 8.x. On reflection, I believe this is because the copy of libutil that's in the misc/compat6x port has not been updated since late Nov 2007, and thus, does not include the fix for FreeBSD-SA-08:01.pty. Should it? Please include me in replies, as I'm not subscribed to -ports@. Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org I submit that "conspiracy" would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Guq+xBHXhbnAFmh4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkeem6UACgkQmprOCmdXAD3cGwCfTVxIdj6XiZ+OT/SdIGkRSkU+ bvQAn1lCloxitUadgZcL4v+OcIIUPgxQ =PrhT -----END PGP SIGNATURE----- --Guq+xBHXhbnAFmh4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080129032111.GH40423>