boyd@necisa.ho.necisa.oz (Boyd Roberts) (10/23/90)
In article <CEDMAN.90Oct17195500@lynx.ps.uci.edu> cedman@lynx.ps.uci.edu (Carl Edman) writes: > >Summary: I think it is a good and simple idea, which (in contrast >to almost all other suggestions made in this group) actually >would work. > No, no, no, no! It may be simple, but it's just not _right_. When you write ASCII bel to some file/tty/whatever you expect to get _one_ ASCII bel. Not two. Just one. It's just a YANDS (Yet Another Nickel and Dime Solution). A proposal to break the tty driver for no good reason, except that it's cheap. Consider a communications protocol that runs across RS-232 via the tty driver. This protocol uses full 7 bit ASCII (or 8 bits if you like). Every once in a while it is _possible_ that an ASCII bel may appear in the byte stream of this protocol (maybe a real bel, maybe ASCII 7 makes up part of a CRC checksum). And at this point another bel is inserted, corrupting the protocol which will result in circuit shutdown. At this rate every second ASCII character will have to have special escapes built in to avoid broken tty drivers. There could be a `character of the day' so that each day a _different_ character would be duplicated. Why stop there? Why not have some magic cursor orientated goo which gets inserted to display some dinky little icon... Where will it end? In the back of my mind I can see the tty driver being hacked so that two bel's on input become one, so broken tty drivers can talk to each other. Even worse, there could be an stty mode that turns this input mapping on and off. But, I won't think about that too hard... With design like this, who needs bugs? Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
cedman@lynx.ps.uci.edu (Carl Edman) (10/23/90)
In article <1884@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: In article <CEDMAN.90Oct17195500@lynx.ps.uci.edu> cedman@lynx.ps.uci.edu (Carl Edman) writes: > >Summary: I think it is a good and simple idea, which (in contrast >to almost all other suggestions made in this group) actually >would work. > No, no, no, no! It may be simple, but it's just not _right_. When you write ASCII bel to some file/tty/whatever you expect to get _one_ ASCII bel. Not two. Just one. It's just a YANDS (Yet Another Nickel and Dime Solution). A proposal to break the tty driver for no good reason, except that it's cheap. Consider a communications protocol that runs across RS-232 via the tty driver. This protocol uses full 7 bit ASCII (or 8 bits if you like). Every once in a while it is _possible_ that an ASCII bel may appear in the byte stream of this protocol (maybe a real bel, maybe ASCII 7 makes up part of a CRC checksum). And at this point another bel is inserted, corrupting the protocol which will result in circuit shutdown. No, no , no, no ! You didn't read what I wrote I explicitly stated that this would only apply to fixed hardwired "dumb" terminals in public access areas. There it is that the problem of spoofs is the greatest and where this feature would be most effective. On this kind of terminal NO compilcated file transfer protocoll is going to run and the system managers will know the kind of terminals they have well enough to always install the right bell character. On the other hand, for dialup lines on which most file transfer protocolls are run there is little (altough not no) chance of spoofs. So this would NOT apply to them. It's O.K. , but I would be grateful if people READ the post they replied to first, BEFORE replying. The argument in the preceeding 2 paragraphs is exactly the one made in my original post and (I think you will agree after having read it) largly invalidates your complaint. Carl Edman Theorectial Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
valdis@wizards.vt.edu (Valdis Kletnieks) (10/24/90)
In article <CEDMAN.90Oct23083648@lynx.ps.uci.edu>, cedman@lynx.ps.uci.edu (Carl Edman) writes: |> No, no , no, no ! You didn't read what I wrote I explicitly stated that |> this would only apply to fixed hardwired "dumb" terminals in public |> access areas. There it is that the problem of spoofs is the greatest |> and where this feature would be most effective. On this kind of terminal |> NO compilcated file transfer protocoll is going to run and the system |> managers will know the kind of terminals they have well enough to |> always install the right bell character. |> |> On the other hand, for dialup lines on which most file transfer protocolls |> are run there is little (altough not no) chance of spoofs. So this |> would NOT apply to them. For the terminally dense among us, explain why a dialup line has less chance of a spoof. I know if *I* were a hacker trying to get a password, I'd rather attack the dialup lines, and suck in the password from somebody who rates a terminal at home, than glom onto a password from some weenie who is still trying to figure out that editors are used to modify files. Dial in, run your program (remember to block SIGHUP), and hang up. Better chance of getting an "interesting" password, and no eyewitnesses ("Yeah, this geeked-out hacker type was there - 5'6, 175, brown hair, scar on left cheek, answered to the name of "Rover"....."). Saying "There's little chance of spoofs, so we won't bother checking for them" is just ASKING for trouble. It's like saying "Well, we're a bank, and since 80% of all bank robbers come in the front door, we'll only put security cameras out front, and hope we dont get hit by the 20% that sneak in the back..." Valdis Kletnieks Computer Systems Engineer Virginia Tech
cedman@lynx.ps.uci.edu (Carl Edman) (10/24/90)
In article <503@vtserf.cc.vt.edu> valdis@wizards.vt.edu (Valdis Kletnieks) writes: In article <CEDMAN.90Oct23083648@lynx.ps.uci.edu>, cedman@lynx.ps.uci.edu (Carl Edman) writes: |> No, no , no, no ! You didn't read what I wrote I explicitly stated that |> this would only apply to fixed hardwired "dumb" terminals in public |> access areas. There it is that the problem of spoofs is the greatest |> and where this feature would be most effective. On this kind of terminal |> NO compilcated file transfer protocoll is going to run and the system |> managers will know the kind of terminals they have well enough to |> always install the right bell character. |> |> On the other hand, for dialup lines on which most file transfer protocolls |> are run there is little (altough not no) chance of spoofs. So this |> would NOT apply to them. For the terminally dense among us, explain why a dialup line has less chance of a spoof. I know if *I* were a hacker trying to get a password, I'd rather attack the dialup lines, and suck in the password from somebody who rates a terminal at home, than glom onto a password from some weenie who is still trying to figure out that editors are used to modify files. Dial in, run your program (remember to block SIGHUP), and hang up. Better chance of getting an "interesting" password, and no eyewitnesses ("Yeah, this geeked-out hacker type was there - 5'6, 175, brown hair, scar on left cheek, answered to the name of "Rover"....."). Please notice: I did not say that spoofs over dialup lines are impossible. Only harder. Yes, you and I know how to get around that minor problem,too, but the C-in-2-weeks loser, who has just learned how to use printf and scanf (that is all it takes to write a spoof on a hardwired terminal) doesn't. And spoofs on dialup lines are easier to combat. One simple (but brutal) way is to make SIGHUP non-catchable. Other, more sophisticated ways include sending all output of programs after SIGHUP to /dev/null. Experienced sys admins will come up with dozen of other (indoubitably better) solutions. Saying "There's little chance of spoofs, so we won't bother checking for them" is just ASKING for trouble. It's like saying "Well, we're a bank, and since 80% of all bank robbers come in the front door, we'll only put security cameras out front, and hope we dont get hit by the 20% that sneak in the back..." I didn't suggest doing NOTHING about them. I merely said that the simple and IMHO clever proposal to double ^G, shouldn't be applied to dialup lines. The reason why this is so have been discussed to death in this thread. Maybe (No, Certainly) there are other ways to combat spoofs there. You misunderstand my position. There are people here who argue that there should be NO cameras anywhere, because they wouldn't work at the back door. I am arguing that it would be a good start to put cameras at the front door, as they will work without problems there. Agreed ? Carl Edman Theorectial Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
boyd@necisa.ho.necisa.oz (Boyd Roberts) (10/25/90)
In article <CEDMAN.90Oct23083648@lynx.ps.uci.edu> cedman@lynx.ps.uci.edu (Carl Edman) writes: > >No, no , no, no ! You didn't read what I wrote I explicitly stated that >this would only apply to fixed hardwired "dumb" terminals in public >access areas. Good to see you like to present a standard interface. When I dial up and login and don't get my two bel's it'll certainly cause some degree of worry. Two bel's good, one bel bad. Isn't that the scenario? > >On the other hand, for dialup lines on which most file transfer protocolls >are run there is little (altough not no) chance of spoofs. So this >would NOT apply to them. > And these dialup lines are not in ``public access areas''. I'd say the phone system is pretty public given that there is large N number of phones on the planet. And dialup lines are _not_ a security problem? Be serious. What you want is better user authentication, not ASCII bel's in the tty output. Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
cedman@lynx.ps.uci.edu (Carl Edman) (10/25/90)
I am getting pretty tired of defending an idea which wasn't even my idea. The only reason I defended it was that I thought it was a cute idea and the arguments made against it so far weren't quite as convincing as those who proposed the thought. In article <1894@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: In article <CEDMAN.90Oct23083648@lynx.ps.uci.edu> cedman@lynx.ps.uci.edu (Carl Edman) writes: > >No, no , no, no ! You didn't read what I wrote I explicitly stated that >this would only apply to fixed hardwired "dumb" terminals in public >access areas. Good to see you like to present a standard interface. When I dial up and login and don't get my two bel's it'll certainly cause some degree of worry. Two bel's good, one bel bad. Isn't that the scenario? I do not present a standard interface. I do not think that this ideas will sweep all UNIX systems in the land and be standard by next Wednesday. I do belive that you are clever enough to figure out after having used a system a few times (and maybe even <gasp !> read the papers you get with an account) whether it has this security feature. > >On the other hand, for dialup lines on which most file transfer protocolls >are run there is little (altough not no) chance of spoofs. So this >would NOT apply to them. > And these dialup lines are not in ``public access areas''. I'd say the phone system is pretty public given that there is large N number of phones on the planet. And dialup lines are _not_ a security problem? Be serious. I did NOT say that they are no security problem. I did say that for reason I outlined in another article a few days ago, they are LESS of a security problem, than public terminals. I gave a list of different security measures you can apply to them. Other people have rejected the entire idea because it would be terrible to apply them to dialup lines (yes, you can not do this as it breaks comm protocolls). And yes , I am being serious. What you want is better user authentication, not ASCII bel's in the tty output. Now what does this mean ? In the last weeks while this discussion raged here almost all proposals this group (supposedly by writen and read by the greatest of unix wizards), ranged from the perfectly foolish to the impracticable. The only one (of those which I read) which had any merit this one, altough I admit that it is NOT a pancaea. Now please describe how your scheme of "better user authentication" would work without assuming equipment and programms on both ends of the lines, which both you and I know won't be standard for the next 5 years. BTW, in my prepubescent youth I used to be a hacker (in the sense of someone who enters computer systems around the world without knowledge or permission of the owners/operators of the system by the use of tricks like the above), so I have SOME idea what I am talking about. Carl Edman Theorectial Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
poc@sun.com (11/15/90)
As the guy who originally posted this idea, I have some comments (sorry if this has all been said before but I seem to have missed out on a lot of intervening discussion). 1) Objections based on breaking network protocols are valid but not insuperable. Decent self-respecting protocols (e.g. IP) can pass true 8-bit data transparently, using character-stuffing if necessary. If UUCP can't, that's a good reason not to use UUCP (though I'm using it now :-) 2) Objections based on breaking cursor-addressing programs like 'vi' are both valid and serious. I can see no way round this short of putting cursor-addressing knowledge in the kernel (yech!) or doing the cursor-addressing through a special process. Window systems essentially do this anyway, but I don't like having even more setuid processes around, not to mention the overhead for every dumb terminal. -- Patrick O'Callaghan UUCP: sun!emsca!usb!poc@sun.com Departamento de Computacion Tel: +058 (2) 9073320, 9073322, 9073363 Universidad Simon Bolivar "The secret is to bang the rocks Caracas, Venezuela together, folks" - Douglas Adams