jfh@rpp386.cactus.org (John F Haugh II) (05/17/91)
In article <3136@cirrusl.UUCP>, dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > In <19281@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > > >Can I change my baud rate while waiting for the SAK sequence? Of > >course there's a need to turn off the SAK key - how long is a UUCP > >packet this week? > > A secure attention key sequence, to be secure, must use an out-of-band > channel. As an analogous example, the DTR line to a modem is > out-of-band and cannot be defeated no matter what you send on the data > lines. Yes. Not everything has an out of band channel to send a SAK sequence along on. For example, what would you use as the SAK sequence on a 3 wire dumb ASCII terminal that is hardwired to a port switch that is used by any number of other terminals with various baud rates and keyboards? There are no spare lines to dork with. Send a break? Do all dumb ASCII keyboards include a BREAK key? It can't be defeated, but no every keyboard has one. Waving "SAK" in front of the problem does not make the issue of authenticating the login process to you any more secure. The issue I keep trying to raise is that it is nice if both the computer and the user clean the line. Dan assures us that for a properly started login process (which he can't guarantee the user is going to press SAK to start) we get a clean line. I say, remove the dependency on the user pressing SAK to start with - let the system clean the line off itself. If the user wants to clean the line, let her nail the SAK key and kill any trojans lurking in the wings. If a system application (for example, passwd) wants to make certain it is talking directly to the authenticated user, let it execute some revoke() process which kills off all untrusted (non-TCB) applications using that port (or some other grotesque action). -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (05/18/91)
In the discussion, Dan mentioned using a secure attention key (SAK)
sequence for security. John objected, saying that the SAK sequence
would have to be disabled for some purposes, such as UUCP. I
responded:
A secure attention key sequence, to be secure, must use an
out-of-band channel. As an analogous example, the DTR line to a
modem is out-of-band and cannot be defeated no matter what you send
on the data lines.
John F Haugh II responds (quite correctly):
Not everything has an out of band channel to send a SAK sequence
along on. For example, what would you use as the SAK sequence on a
3 wire dumb ASCII terminal that is hardwired to a port switch that
is used by any number of other terminals with various baud rates and
keyboards? There are no spare lines to dork with. Send a break?
Do all dumb ASCII keyboards include a BREAK key? It can't be
defeated, but not every keyboard has one.
Dan will, of course, have his own response to this (as he always
does :-). Although it's true that not all hardware guarantees an
out-of-band channel to support a secure attention key, it turns out
that there is a simple method of using in-band signalling that is
*virtually* foolproof. The good folks at Bizcomp patented this some
years ago. (Maybe I should say the "bad" folks, because they then
proceeded to sue everybody in sight.) The idea is to have a secure
attention sequence that includes guard pauses before and after. In the
case of the most popular application of this patent, the sequence used
is:
(1 second pause) +++ (1 second pause)
When the above happens on the data line, a modem that understands it
goes into command mode.
I said *virtually* foolproof because there is a finite, though
infinitesimal, chance that a genuine data stream will include the same
sequence. If it does, you are in trouble. It doesn't happen in
practice, probably for the same reason that an ideal gas in a box never
collects all in one corner, though the quantum mechanics (mechanicists?
machinists?) will tell you that, given enough time, it *will* happen.
Probably 99.9% of dumb terminals have a real break key. Users of the
remaining 0.1% may have to do something like this:
1. pause for 3 to 5 seconds
2. rapidly hit the + key 10 times
3. pause for 3 to 5 seconds
4. hit the return key
The chances of the pauses accidentally occuring in the same way in a
data stream are probably very small. To make the sequence even more
foolproof you can increase the pauses, or require a longer
sequence like:
(pause) +++ (pause) --- (pause) &&& (pause)
--
Rahul Dhesi <dhesi@cirrus.COM>
UUCP: oliveb!cirrusl!dhesijfh@rpp386.cactus.org (John F Haugh II) (05/19/91)
In article <3140@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: >Dan will, of course, have his own response to this (as he always >does :-). Yes, I have read the specification for the Dan Bernstein Window Manager. It argues with your for 15 minutes and still doesn't resize the window ... > Although it's true that not all hardware guarantees an >out-of-band channel to support a secure attention key, it turns out >that there is a simple method of using in-band signalling that is >*virtually* foolproof. The problem is that it must be =absolutely= foolproof. If I can come up with even one way to circumvent it, it isn't usable as a SAK sequence. AT&T with the SV/MLS product uses DTR as the out-of-band signal. What about three-wire terminals? [ The answer there is that if you don't use exactly the set up the NCSC evaluated, your milage may vary ;-) ] > (1 second pause) +++ (1 second pause) > >When the above happens on the data line, a modem that understands it >goes into command mode. Every second I send an answer-back request to your terminal. Once a second I receive the answer-back, strip it out from whatever you type, and pass that along unchanged to the rest of the system. You never notice anything funny because you aren't talking to the hardware anyhow, but rather my little trojan horse that is pretending to be the login program. It's obvious that you are thinking a lot harder than Dan, but it isn't clear that you understand the nature of the problem. A SAK squence must be absolutely uninteruptable (for lack of a better word). I don't think it is possible for a single SAK sequence to apply to all possible login session types for more than the smallest collection of hardware. I think it takes a multiple choice approach. But SAK alone is not the end-all to security. You also need an application that can do useful things with SAK, and Dan's suggestion that every SAK kills everything on the line is just too gross. If the user can't SAK at any time, they will never SAK. And that means any need for the SAK key during crucial operations (like changing your password) will not be met - what, press SAK and kill my XBIFF? -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/19/91)
In article <19306@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > Yes. Not everything has an out of band channel to send a SAK sequence > along on. Then the sequence must be in-band. For the sake of argument, let's say that getty (or whatever process does the I/O on a hardwired line) checks for ^K everywhere in the input stream. ^K<space> is translated into a ^K for the underlying session, and ^K<anything else> disconnects the session for later reconnection and provides a login prompt. That's a secure attention key, and one which cannot be defeated on most terminals. (The exceptions are those terminals which can somehow be forced to silently transmit a space right after the user types ^K, and those in which the ^K key itself can be reprogrammed.) > Dan assures us that > for a properly started login process (which he can't guarantee the > user is going to press SAK to start) we get a clean line. What's the point of your parenthetical comment? The system documentation will tell users that they should press ^K a few times to get a login prompt. Otherwise, sayeth the docs, some other user might be faking the login prompt, and that's a Bad Thing. In any case, yes, I assert that my solution provides a secure tty, and I've explained in another article exactly why this is true. > I say, > remove the dependency on the user pressing SAK to start with - let > the system clean the line off itself. If the user wants to clean the > line, let her nail the SAK key and kill any trojans lurking in the > wings. Frankly, John, that is one of the most idiotic statements I've ever heard from you. You complain about my solution because it can't stop stupid users from telling other users their passwords, but you want to trust the user to press SAK after he's given away the password? Wake up. Revoking tty access does not solve any more problems than my solution does, and your ridiculous ideas about how a SAK can be implemented have nothing to do with tty security. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/19/91)
In article <19309@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > It's obvious that you are thinking a lot harder than Dan, but it > isn't clear that you understand the nature of the problem. A SAK > squence must be absolutely uninteruptable (for lack of a better > word). John, I am assuming the existence of a well-known SAK for a given line, and pointing out how it can be used to increase security. You're attacking the mere concept of an SAK. As Multics and several other operating systems showed quite clearly, SAKs do exist, so any arguments to the contrary are wrong. > But SAK alone is not the end-all to security. You also need an > application that can do useful things with SAK, and Dan's suggestion > that every SAK kills everything on the line is just too gross. I have never made any such suggestion, and I despise the way that you have misrepresented my proposals. I advise readers to check my postings rather than believing John's statements about them. (What I actually suggested is that SAK disconnect the current session. This means that the user can later log in again and reconnect, resuming work where he left off. For further details on session management, see my pty paper, Bellovin's session manager paper, or VMS documentation.) ---Dan
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (05/20/91)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > (pause) +++ (pause) --- (pause) &&& (pause) > -- > Rahul Dhesi <dhesi@cirrus.COM> > UUCP: oliveb!cirrusl!dhesi Of course, you actually don't want to use the sequence (pause) +++ (pause), because that will produce really confusing results if someone ever tries to invoke it over a modem that recognizes that. Of course, a modem connection isn't all that secure anyway because it's easy to tap, but someone might still consider themselves secure enough despite that. On the other hand, an in-band SAK sequence over the phone would be a dead giveaway to someone wathing that you're about to type something sensitive, like a password. -------------------- Jeffrey Hutzelman America Online: JeffreyH11 Internet: jh4o+@andrew.cmu.edu BITNET: JHUTZ@DRYCAS >> Apple // Forever!!! <<
jfh@rpp386.cactus.org (John F Haugh II) (05/21/91)
In article <16215@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >Gee, nice diagrams. If done earlier, it might have saved a thousand words. The problem is that his diagrams still didn't answer the question. I don't care about what happens at login time, but rather what happens well after login time. >Ready for the next question? Why an SAK like ^K? Why not just have loss >of DTR be the attention signal? You're going to blow off the previous >session anyway, might as well let terminal poweroff automatically serve >as your SAK. (Yes, I know you have to wire and configure things correctly, >but that sort of argument applies to any scheme.) AT&T, in their SV/MLS system, supports 3 different SAK mechanisms for the 630 MTG terminal. They are 1) power cycling, 2) <CTRL><BREAK> and 3) <SHIFT><CTRL><ESC>. I'd wager that the hardware guys prefer you don't power cycle because of the stress that places on the hardware compared to a simple keystroke sequence. [ I'm sure the customers would prefer the system not nuke everything in sight. ] -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
smb@ulysses.att.com (Steven Bellovin) (05/22/91)
In article <19323@rpp386.cactus.org>, jfh@rpp386.cactus.org (John F Haugh II) writes: > AT&T, in their SV/MLS system, supports 3 different SAK mechanisms for > the 630 MTG terminal. They are 1) power cycling, 2) <CTRL><BREAK> > and 3) <SHIFT><CTRL><ESC>. I'd wager that the hardware guys prefer > you don't power cycle because of the stress that places on the > hardware compared to a simple keystroke sequence. [ I'm sure the > customers would prefer the system not nuke everything in sight. ] Umm -- ctrl-BREAK drops DTR, which is one solution already suggested. And ctrl-shift-ESC on the 630 is the reset sequence, which not only drops DTR, but also wipes the program cache, the font cache, etc., on the terminal. In other words, it's the software equivalent of power-cycling...
jfh@rpp386.cactus.org (John F Haugh II) (05/22/91)
In article <14858@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes: >Umm -- ctrl-BREAK drops DTR, which is one solution already suggested. >And ctrl-shift-ESC on the 630 is the reset sequence, which not only >drops DTR, but also wipes the program cache, the font cache, etc., >on the terminal. In other words, it's the software equivalent of >power-cycling... It is not, however, the =hardware= equivalent of power cycling. As is often argued [ religiously ] on various groups, power cycling is bad for your equipment. That's why I said that the hardware weenies probably would rather that you use the keyboard SAK varieties. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."