3 ms·
It 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 loo
by burnte 9y ago
It 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.
- jakobegger 9y agoMost major security breaches are not caused by explicit back doors — they are caused by accidental vulnerabilities. If you leak user data accidentally, saying “that wasn’t my intent” doesn’t help much. The important thing that you don’t understand is that there is a difference between a search field / url box, and a Terminal. I absolutely expect my browser to make DNS queries for stuff I paste into the URL box. I don’t expect my terminal emulator to make DNS queries for random strings displayed on screen that happen to match a regex.
- burnte 9y agoThis wasn't an accident, it deliberately looked up domain looking string against a DNS server. Don't patronize me, going by your twitter picture, I've been at a command shell longer than you've been alive, I damn well know the difference. I also know that doing DNS lookups (the the user's chosen DNS server, rather than some secret one) on domain-name looking data isn't evil or completely unreasonable. He should have made it clear and opt-in rather than opt-out as it was, but by no means was this a vulnerability. If the user can't trust their domain server for domain-like data, they shouldn't use that server.
- jakobegger 9y agoLet me quote the original issue report on Github: > What happened: iTerm sent various things (including passwords) in plain text to my ISP's DNS server iTerm was accidentally transmitting passwords in plain text via the network. I'm pretty sure transmitting passwords in plain text isn't "working as intended". Sure, you can go blame the user for not knowing that iTerm makes DNS queries when you hold down the command key. But if you want to make secure software, you can't just tell the user it's their fault. You need to make sure that accidentally disclosing private information is not something that easily happens.
- burnte 9y agoYou're purposefully putting intent on software. It didn't send passwords, it sent strings that looked like a domain to a regex. It did not send a message to a DNS server "Hey DNS server, this is a password!" The user happened to want to use that string for a password.
- jakobegger 9y agoOK, you win. I can’t follow your arguments anymore. I must be too young and unexperienced.