9 ms·
iTerm2: Please disable 'Perform DNS lookups to check if URLs are valid'
- jakobegger 9y agoIt never ceases to amaze me how otherwise intelligent people think it‘s a good idea to send unencrypted user data to random servers on the internet in the background.
- JadeNB 9y agoIt makes me scared to be an iTerm2 user, frankly. Because I am an idiot, it never occurred to me that I'd have to wonder about the security implications of my choice of terminal emulator. Does it otherwise have a good reputation for security?
- problems 9y agoJust ditch it - clearly the author has no regard for privacy. I cringe just thinking about implementing something like that.
- mw6621 9y agoiTerm2 is great and George is absolutely responsive with any issue I've ever brought up. I am personally going to give him the benefit of the doubt here, I'm sure he'll fix things ASAP.
- deleted 9y ago[deleted]
- derimagia 9y agoYep was already fixed: https://gitlab.com/gnachman/iterm2/wikis/dnslookupissue https://gitlab.com/gnachman/iterm2/wikis/dnslookupissue
- 0culus 9y agoI don't think it's worth throwing the baby out with the bathwater. But this should at a minimum be an opt-in feature, and not opt-out. Better yet, it's probably not needed. I've almost never needed to interact with URLs in a clickable way via a terminal.
- sametmax 9y agoI do but I always know if they are valid before I click on them, so I don't see the appeal of the DNS lookup. Plus that must be freaking slow.
- JosephRedfern 9y agoNot necessarily slow, DNS Lookups are generally pretty fast: ~ dig somerandomurlimadeup.com | grep 'Query time: ' ;; Query time: 23 msec
- greglindahl 9y agoEr, that's just saying "you got lucky and the root nameserver you hit was fast". Looking up any valid .com requires that plus a 2nd level lookup.
- alanh 9y agooh wow, what would that make it, 50ms? that's almost enough time to blink!
- sametmax 9y agoCompare to the rest of the operations your terminal do, it's crazy slow though.
- JosephRedfern 9y agoI tried on several domain names (that I had not, to my knowledge, recently visited), and they were all around the 25ms mark. I'm not saying that this is the case universally, but for many the typical lookup time will be very fast.
- exikyut 9y agoThe author has fixed it, and clearly this has been an educational experience. Considering the professionalness of the rest of the app, I get the impression that the author is likely going to factor security considerations into the picture in a big way in the future.
- bluedino 9y agoI used to use it religiously but recently went back to Terminal on my last two Macs and don’t really miss anything
- burnte 9y agoCome on, it's doing domain lookups, it's not sending social security numbers to Russia. The amount of hyperbole regarding this misfeature is absurd. It was something that maybe should have been better expressed but this is not some kind of massive security failure.
- jakobegger 9y agoIt doesn’t matter what the code intends to do. Sure, looking up strings that look like domains seems harmless. But it means that every string that looks like a domain is transmitted unencrypted over the internet. If your software deals with private user data, you must consider the side effects of every API you are calling. You can’t just transmit data somewhere and hope that everyone will do the right thing. Network traffic is monitored on lots of networks. Unless the data is encrypted and you have reason to trust the receiver, don’t send it. And whatever you do, don’t send private data without user action. Users expect web requests to be made when clicking a link. They do not expect data to be transmitted when hovering the mouse over URLs.
- burnte 9y agoIt absolutely matters what the code intends to do. If it intends to do a DNS lookup, and does that, that's working properly, eepecially if it's doing an DNS lookup on what its regex says looks like a clickable URL. If it means to store an SSN in an encrypted DB and accidentally writes it to plaintext or sends it to twitter, that's a security flaw. If that same app is following the system standard method of doing DNS resolutions, what else should it do? Are you really suggesting that it should somehow encrypt a DNS lookup? Why should this app be held to a higher standard than every single other application that does DNS lookups? This is the absurdity I'm talking about. I completely agree that one must take into account how that feature fits with your product, user expectations, and privacy, but none of that means a feature that works as intended is a security flaw. As others have said, prefetching pages has been done for years. Checking to see if it's a valid domain isn't an unreasonable feature for iTerm's URL highlighting, and for those who would prefer it not, he's changed that behavior, but let's not pretend that it was some absurd use of data that no one could have reasonably predicted. And lastly, let's also stop clutching our pearls about "transmitting data". IT did a DNS lookup, and while technically that means there was a transmission, it wasn't taking what people traditionally call user data and transmitting it to a foreign third party. It's perfectly reasonable to check a domain name against a DNS server. Maybe unwanted, yes, but not even remotely irrational or irresponsible.
- JadeNB 9y agoSince I didn't see it on a quick skim, it seems that the way to do this is Preferences > Advanced > Semantic history.
- chadlavi 9y agoOr if you're lazy like me, Preferences > Advanced > type "DNS" (the search field gets autofocus on the Advanced prefs pane).
- whoisjohnkid 9y agolol this is exactly what I did. Worked like a charm.
- casey_lang 9y agoBased on this note[1], you can also disable with: Preferences > Pointer > CMD+Click Opens Filename/URL [1]https://gitlab.com/gnachman/iterm2/issues/3688#note_1665347 https://gitlab.com/gnachman/iterm2/issues/3688#note_1665347
- JadeNB 9y agoThis throws out behaviour that some people find desireable (for example https://news.ycombinator.com/item?id=15288935 https://news.ycombinator.com/item?id=15288935 ), whereas it is possible to keep that behaviour without the privacy violations.
- clairity 9y agoa local firewall (hands off & little snitch are handy commercial ones for mac) will help you catch these kinds of info leaks (i caught this one a long time ago because of mine). it does come with a time cost however--little popups every time you launch a new application or connect to a new service that you have to evaluate and handle, since you haven't set rules for them already.
- duskwuff 9y agoA local firewall probably wouldn't have helped here -- the DNS lookups would be performed by mDNSResponder, not by iTerm itself.
- clairity 9y agoyou might be right about the DNS lookup. but i do distinctly remember getting alerts for this and being annoyed enough to go figure out how to disable the feature in iterm2 (it was at least a couple years ago, so my memory is hazy). maybe someone with more recent experience can clear up the mystery for us. =)
- ThisIs_MyName 9y agoI don't think this "feature" existed a couple of years ago.
- clairity 9y agoi think it was probably link pre-fetch that triggered the firewall rather than a dns lookup.
- deleted 9y ago[deleted]
- csours 9y agoWow, this reminds me of how Cisco routers automatically try to SSH to anything that isn't a recognized command. (I may be mis-remembering part of this)
- gnachman 9y agoGiven the level of concern, I will change the default and release a new version right away.
- tuxxy 9y agoThanks for your quick work on this. It's very much appreciated by security minded users of iTerm2. :)
- mrmondo 9y agoThank you, very much appreciate your response (and continuing excellent work on iterm).
- gnachman 9y agoThis is done. A summary of the issue and apology can be found here: https://gitlab.com/gnachman/iterm2/wikis/dnslookupissue https://gitlab.com/gnachman/iterm2/wikis/dnslookupissue
- lobster_johnson 9y agoThank you. Will you be releasing a new beta, too?
- gnachman 9y agoYep. I'll put that out tonight.
- zbobet2012 9y agoMistakes happen. Quick responses and honest apologies are always appreciated!
- beager 9y agoThanks for owning it and thanks for fixing it. Better response than you're likely to get almost anywhere!
- ak217 9y ago
- JosephRedfern 9y agoI've submitted a PR to change the default behaviour: https://github.com/gnachman/iTerm2/pull/332 https://github.com/gnachman/iTerm2/pull/332
- deleted 9y ago[deleted]
- tlb 9y agoIt's horrifying to watch your own DNS traffic. All sorts of mysterious domains show up. (On a typical macbook on WiFi, this will do it:) sudo tcpdump -i en0 -s 5000 -n port 53 On mine, these get resolved every 30 seconds (probably some Adobe updater): scss-prod-ue1-notif-39.adobesc.com. Several servers get lookups of names long enough to be exfiltrating data: r3---sn-nvopjoxu-25ve.gvt1.com. (Google) gzunified-ecselast-1isehuisml2g4-663788831.us-east-1.elb.amazonaws.com. (???) kube-nimbus-471965604.us-west-2.elb.amazonaws.com. (BitDefender) If you hit a popular commercial site without AdBlock enabled, the list is loooong and sketchy-looking.
- Twirrim 9y ago> sudo tcpdump -i en0 -s 5000 -n port 53 It may be better to do it like this: sudo tcpdump -i any -s 0 -n port 53 That way you'll get to see every single DNS query made, and capture everything about it.
- exikyut 9y agoThat Google one uses a similar naming scheme to the servers used for video data for YouTube etc. You just made me realize something, though. The Google and AWS examples you gave won't be able to do this, but if you set up wildcard DNS and tell DNS that you have your own nameserver via CNAME aliasing, you could make your software do a lookup for eg something like "bm9ib2R5IHdpbGwgZXZlciBub3RpY2UgaWYgSSB0cmFuc21pdCBkYXRhIGxpa2UgdGhpcyEKCg.example.com" and exfiltrate data via DNS request in the process. The server could then return 127.0.53.53 to mean "ACK; data received OK", whereas NXDOMAIN or any other error would mean to try again. Hmmmmm. Wondering if I should delete this... (I realize this is exactly how the Iodine DNS tunnel works. FWIW, freedns.afraid.org's free options are perfectly capable to get iodine working, I was very pleased to discover.)
- emmelaich 9y agoI believe it's common for malware to beacon out with a similar method.
- 9y ago
- geofft 9y agoOne of the nice things about GitLab instead of GitHub is that there isn't a flood of low-information, high-anger comments once a thread makes the HN front page.
- davidgerard 9y agoNo, that's because the server is melting and giving 500 errors ;-)
- stiangrindvoll 9y agoMakes you wonder how your own port 53 traffic looks like...
- pishpash 9y agoWhat's more interesting to me is that some people are okay with a lookup on click but not a lookup on hover. It seems a difference in affirmative intent exists between hover and click; and more generally perhaps categories of user actions should be formalized into degrees of affirmation that could mitigate errors like this.
- justinclift 9y agoHovering can be a part of the everyday copy-n-paste action though, for selecting the text to copy.
- EnigmaticLion 9y agoIf i use iTerm's autocopy feature (e.g. that the selected text automatically goes to the clipboard) and rarely press CMD+C then i'm safe? Or should i start changing my passwords? Since i usually generate passwords with `pwgen`, then copy with double click.
- justinclift 9y agoSorry, no idea personally. I don't use iTerm, I was just pointing out that hovering is a common user action (due to cut-n-paste). :)
- hannob 9y agoReminded me immediately about this whatsapp-issue, which is also very problematic: https://twitter.com/mulander/status/874370124932943874 https://twitter.com/mulander/status/874370124932943874
- exikyut 9y agoAlso affects FB Messenger (scroll down the thread for a while) and Telegram. A WA crash was also presented. Well that was a very interesting thread...
- knodi 9y agoIs gitlab throwing a 500 for anyone else?
- sytse 9y agoIt was but it was fixed, see https://twitter.com/gitlabstatus/status/910274484992663552 https://twitter.com/gitlabstatus/status/910274484992663552
- deleted 9y ago[deleted]
- Azkar 9y agoFantastic response. ~4 hours from report to release.
- cnst 9y ago4 hours? More like 2 years! And at least 3 separate bug reports, roughly one year apart each! https://gitlab.com/gnachman/iterm2/issues/3688 https://gitlab.com/gnachman/iterm2/issues/3688 https://gitlab.com/gnachman/iterm2/issues/5303 https://gitlab.com/gnachman/iterm2/issues/5303 Unless you are into alternative facts, of course, then, yeah, very prompt release engineering and vulnerability fixing!
- kator 9y agoI hardly go a day without using iTerm2. Don't worry George your responsiveness more than makes up for an honest mistake. To everyone else: I would highly recommend if you make money on a daily basis using iTerm2 that you support his efforts: https://www.patreon.com/gnachman/posts https://www.patreon.com/gnachman/posts Before you ask, yes I'm a patreon for George, his work inspires me.
- dawnerd 9y agoI had no idea who was behind the project or that they even had a patreon. Going to chip in now. Thanks
- sgt 9y agoI recently switched back to Terminal.app due to poor performance in iTerm 2. Keystrokes were lagging to the point it got frustrating. Then a few days ago someone pointed out that I should try the iTerm 2 nightly build, and sure enough the lag is gone, so I'm now back on iTerm 2 again.
- _of 9y agoI just upgraded. Is there any way to turn off the new Iterm2-specific MacBook touch-bar buttons?
- NelsonMinar 9y agoIt's a shame DNS traffic isn't at least encrypted. That doesn't solve the whole problem (you're still sending data to a potentially untrusted DNS server) but it'd help a little.
- trapperkeeper74 9y agoIn general, dnscrypt can help defend against DNS privacy loss for situations like these.
- Habbie 9y agoYou said it right - can help defend. On the other end of your dnscrypt tunnel, the queries will still go out unencrypted. They will just be harder to correlate to you specifically.
- cnst 9y agoCVE-2015-9231 has been assigned to this issue. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-9231 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-9231 https://nvd.nist.gov/vuln/detail/CVE-2015-9231 https://nvd.nist.gov/vuln/detail/CVE-2015-9231