Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!newsroom.utas.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!gatech!hookup!olivea!grapevine.lcs.mit.edu!usenet@lcs.mit.edu From: shep@ginger.lcs.mit.edu (Tim Shepard) Newsgroups: comp.protocols.kerberos,comp.bugs.4bsd Subject: Re: krlogin/krlogind usage of OOB data is broken Date: 15 Feb 1996 16:23:47 -0500 Organization: MIT LCS Lines: 59 Sender: shep@ginger.lcs.mit.edu Message-ID: <ridenrwqo4c.fsf@ginger.lcs.mit.edu> References: <4fiobt$590@jik.datasrv.co.il> NNTP-Posting-Host: ginger.lcs.mit.edu In-reply-to: jik@annex-1-slip-jik.cam.ov.com's message of 10 Feb 1996 18:32:09 GMT X-Newsreader: Gnus v5.1 Xref: euryale.cc.adfa.oz.au comp.protocols.kerberos:5371 comp.bugs.4bsd:2092 In article <4fiobt$590@jik.datasrv.co.il> jik@annex-1-slip-jik.cam.ov.com (Jonathan Kamens) writes: [...] >come to the conclusion that the way [krlogin] uses OOB data is broken in at >least on[e] way that simply cannot be fixed without changing the protocol. [...] >The basic problem I'm encountering is this: What happens if krlogind sends an >OOB message to krlogin, and then it sends a *second* OOB message before >krlogin has processed the first one? This *can* and *does* happen. For >example, when I krlogin from my Linux box at home to an AIX box at work over a [...] >Unfortunately, the way OOB data is implemented in the Linux kernel (and I >believe in many other UNIX kernels as well) is that only one OOB message is >allowed at a time. If a second message is received while the first one is >still pending, the first one becomes part of the normal data stream, and the >OOB mark is moved to the second one. This does appear to be legal, according >to the BSD documentation about OOB data. Consider what occurs if this happens [...] >I would appreciate any input that people might have into this problem. Am I >right that there's a problem? Has it always been there? Is there any way to >solve it, short of either (a) modifying the protocol in a way that isn't >backward-compatible, or (b) ditching krlogin/krlogind altogether and using >ktelnet/ktelnetd instead [...] I'm very happy to see that someone is pursuing this bug. I've been bitten by it many times over past six or so years. It usually happens to me when I type ^C to stop a program that is sending lots of output to the terminal. The connection is then instantly lost. A friend of mine and I investigated this problem a few years ago and came to the same conclusions that you have, but we did not get as far as you. Neither of us were hard-core kerberos hackers, and other distractions were more important than this one, so we just trained our fingers to never use ^C to stop large amounts of output spewing at us over an encrypted krlogin connnection. The root of this bug is in the way the BSD socket semantics are implemented over TCP. TCP does not have an out-of-band data mechanism. It has only an unreliable urgent pointer. The way MSG_OOB is currently implemented over TCP (by using the urgent pointer) there is no guarantee that data sent with MSG_OOB will not wind up in-band at the other end. The problems with krlogin apparently demonstrate that this does indeed happen. I believe you are right on target with your analysis. Yes, a protocol change is apparently needed in krlogin to make it robust in light of this problem. I've never seen any similar problem with the regular BSD rlogin program. I have not investigated why it would not have the problem, but I would guess that it is prepared to correctly handle OOB data that has wound up in-band (which is IMHO the right way to cope with this problem). I hope this is of some help to you. -Tim