Excerpts from Keith Winstein's message of 2013-12-19 10:21:04 +1300: > To be honest, up to this point we have mostly thought of mosh-server as an > unprivileged process run by users. The debugging output from a user's > mosh-server is not something we imagined system administrators would care > that much about, any more than the debugging output from a user's screen or > tmux or pine.
Having the mosh-server as a user process is fine, and renders a large number of attacks irrelevant -- for example, I could try to break the shell quoting of the mosh command to run something unexpected on the server, but given the assumption is that I could log in there anyway to get an interactive shell, there's no point :-) And I'm not interested in the Send|Received messages that are tracking acks and rtt values; that's much more valuable for people tracking performance (which is of course a large part of what mosh is for). But from the perspective of a security-minded system administrator, I need to know what my users are doing, when they are doing it and from where. If any aspect of a user's credentials falls under the control of the 'bad guys' it'll be literally moments before I start to see connections from the poorly-enforced parts of the Internet; Nigeria, Russia, China and so on. You'll probably be able to count this scenario as a 'win' for mosh due to popularity :-), but one day soon there'll be malware that looks for mosh state information on a machine (rather than do keylogging to wait for them to type in a password) -- once they have stolen the key from whatever program is using or storing it, they'll be able to immediately send packets to the server using that key (and just set the sequence number to something high, to trump the real process) from their own IP. This doesn't just get them a login to the server; this also gets them full access to whatever other systems the user session is also authenticated to (i.e. machines that are not directly exposed to the Internet). So as the system administrator, I need to be able to log what the mosh-server is doing in respect of 'connections' -- and pretty much all because you're not using TCP and you're promoting mobility (which should have been in TCP from day one, but isn't because IP addresses were reused for the nest layer's addressing as well). I already get to see ssh's connections, because the ssh listener is controlled by root, and logging isn't a user preference. > So we haven't really designed for this use-case. If you are really > interested in logging packets that fail to verify the integrity check, > syslog may be appropriate, or maybe some sort of systemd facility -- I'm > not sure what's in vogue these days. Syslog is still the most appropriate choice, and gives you the widest platform range. After a quick glance at your code, I'd expect that you'd get pretty much all of it achieved by adding a syslog invocation immediately after nearly every "fprintf(stderr,...)" in mosh-server.cc > Can you tell us more about your needs -- do you plan to analyze to see > where the bogus packets are coming from (in which case we will need to > print out the source IP and port, which we don't do currently), or...? The bogus packets are slightly different; from a security perspective I'd say "the more data the better". But these packets are by definition ones that don't gain privilege, so we don't have to go overboard with them. I am concerned that a DoS attack might be plausible (i.e. where a level of incoming data is not enough to destabilise the server itself (because if it is big enough to do this, it isn't exactly your problem alone), but still manages to render a given mosh session unuseable), so we don't want to spend too much CPU time on each one. It's probably fine to only log these when actively doing debug, same as with the Sent|Received data. There's another case I touched on in that speculative malware section above; I'm assuming that if the bad guys get the session key, all they have to do it to create a "bigger" sequence number and they are automatically more preferred than the real client. Is that correct? Are smaller sequence numbers logged as bogus? How big can the sequence numbers go, what happens when the number wraps back to zero? -jim -- Jim Cheetham, Information Security, University of Otago, Dunedin, N.Z. ✉ jim.cheet...@otago.ac.nz ☏ +64 3 470 4670 ☏ m +64 21 227 0015 ⚷ OpenPGP: B50F BE3B D49B 3A8A 9CC3 8966 9374 82CD C982 0605
signature.asc
Description: PGP signature
_______________________________________________ mosh-users mailing list mosh-users@mit.edu http://mailman.mit.edu/mailman/listinfo/mosh-users
