Quite often you can be in a situation where you need to poke into an already running app e.g. used by a QA person or a simple random employee in the office.
Because it looks like this actually is telnet as opposed to ssh, let's make one thing clear:
In telnet, everything is sent unencrypted. Even passwords. Especially passwords. Telnet does not encrypt passwords. Passwords are sent in the clear. Anyone snooping your traffic could read all of your passwords if you send them over a telnet session.
I hope that was just enough verbiage to make certain at least one person gets the message.
Yes this is Telnet, not SSH and you certainly wouldn't want to ship it enabled by default: it should be enabled on Debug builds only or have some explicit switch for testers, etc...
The primary use of this library is for development and field debugging and for that it can be very valuable: you can connect to your app (while it's running of course) from pretty much any computer. There are also some use cases in production that expose no security risks (apps are sandboxed after all and far from every app deals with password or sensitive data).
iOS apps are heavily sandboxed, have non-executable memory pages, can't even run in the background, this library doesn't implement a shell at all, etc... so what would be a "massive" security hole here?
Of course, it could be used poorly, like a number of other libraries (not validating HTTPS certs anyone?), and introduce a security issue which would only have an effect in apps that deal with sensitive data and transmit said data using this Telnet library.
IMO it's no different from running, say, an HTTP web server from an iOS app which a number do.
Thanks for sharing a really useful debugging tool. It's kind of funny how much flack you are getting for posting this, when I read the subject line, I knew it was intended only for development use.
My pleasure! It's certainly been very useful to me to have Telnet capabilities into an iOS app, and same for coworkers I introduced this feature to.
I think some people like to be all high and mighty about security issues and derive pleasure from pointing out (often adamantly) what they see as flaws while often these are expected and well understood side-effects, and in no way "real" security issues.
I think this is great! I am going to use this to create a debugging version of my Mac app, for the times when I am at a loss for what is going on, I can have the user install this version and then give me their IP address and I can have a better way of seeing whats up. Thanks for sharing!
15 comments
[ 3.0 ms ] story [ 36.4 ms ] threadI mean, I get the utility, but it seems like a massive security hole.
In telnet, everything is sent unencrypted. Even passwords. Especially passwords. Telnet does not encrypt passwords. Passwords are sent in the clear. Anyone snooping your traffic could read all of your passwords if you send them over a telnet session.
I hope that was just enough verbiage to make certain at least one person gets the message.
All types of shenanigans could potentially be had with this though. I personally would not like installing an app with this lib.
The primary use of this library is for development and field debugging and for that it can be very valuable: you can connect to your app (while it's running of course) from pretty much any computer. There are also some use cases in production that expose no security risks (apps are sandboxed after all and far from every app deals with password or sensitive data).
Yep. Plenty of verbiage. All of it invalid, however.
This code doesn't run login or link PAM. It doesn't authenticate.
No username or password will ever be prompted for, or sniffed.
Of course, it could be used poorly, like a number of other libraries (not validating HTTPS certs anyone?), and introduce a security issue which would only have an effect in apps that deal with sensitive data and transmit said data using this Telnet library.
IMO it's no different from running, say, an HTTP web server from an iOS app which a number do.
I think some people like to be all high and mighty about security issues and derive pleasure from pointing out (often adamantly) what they see as flaws while often these are expected and well understood side-effects, and in no way "real" security issues.