Description: Eric Johanson has reported a security issue in Konqueror, which can be exploited by a malicious web site to spoof the URL displayed in the address bar and status bar. The problem is caused due to an unintended result of the IDN (International Domain Name) implementation, which allows using international characters in domain names. This can be exploited by registering domain names with certain international characters that resembles other commonly used characters, thereby causing the user to believe they are on a trusted site. Secunia has constructed a test, which can be used to check if your browser is affected by this issue: http://secunia.com/multiple_browsers_idn_spoofing_test/ The issue has been confirmed in version 3.2.2. Other versions may also be affected. Solution: Don't follow links from untrusted sources. Manually type the URL in the address bar.
Confirmed on 3.3.2 KDE please advise.
Well, there are people, who want to use international characters in domain names. It's not unintended, it's just a problem, that it's so easy to confuse characters, which look more or less the same. Unfortunately confusable charactes are, what IDN is about. We could make libidn optional and warn about it, but e.g. Kopete's Jabber plugin won't work without it. Users just have to look at certificates when they enter security relevant sites and not simply click o.k.. I don't think we should do something about it.
http://www.icann.org/committees/idn/idn-codepoint-paper.htm is a nice read
http://bugs.kde.org/show_bug.cgi?id=98788
*** Bug 81594 has been marked as a duplicate of this bug. ***
There are two things we can do here: Wait until the KDE folks comes up with a fix or Disable IDN support by default without a use flag
Security team, your opinion? Do we have a relevant policy or commitment? If you tell us to disable it, the same should apply to mozilla-derived browsers.
My opinion is to wait for the upstream fix. This is a minor issue (spoofing). I wouldn't have sung the same tune were it more serious.
I agree. Let's wait for upstream.
I don't, mostly because I don't have the feeling that upstream will resolve this very soon. IMO the Mozilla devs did the right thing today when announcing to disable IDN in future Mozilla and Firefox versions. Furthermore punycoded domains aren't very widespread yet (and until recently you had to care for IDN support in Konqueror yourself), so disabling -- or at least making it optional -- probably won't hurt many. Anyhow: Isn't there at least some way to manually disable IDN support for those of us who don't like to take that risk? I haven't found a possibility in the Konqueror settings and just unmerging libidn is out of the question, since kdelibs has a non-optional dependency on it. I'd really like to get rid of IDN support until a secure solution has been found.
>who don't like to take that risk? "Which risk?" Do you really look at every link character for character? Even with ASCII it's possible to confuse o and 0, i and l, 5 and S - especially if you're in a hurry. There are lots of other ways of trickery. The web is untrusted. No need to panic. :)
>>who don't like to take that risk? >"Which risk?" I do in fact take a close look when I'm forwarded to a site like PayPal and can clearly distinguish between ASCII characters. However, in the example given at http://www.shmoo.com/idn/ I can't see a difference between the fake and the real URL, at least not by just looking at it. Some time ago the guys at shmoo.com registered a fake paypal.com domain for demonstration purposes, which was even more impressive and if it would have been for real, a lot of users -- probably including me -- would've fallen for it. When I follow a link or when I'm forwarded to another site which wants me to enter sensible information (like my PayPal login and password), the only way with IDN support enabled is to enter the URL manually. This can be very inconvenient, especially when information between both sites is supposed to be transmitted via e. g. HTTP POST or the referrer. And you surely know what users usually do, when security can only be obtained by doing something inconvenient. :)
>...when I'm forwarded to another site which wants me to enter sensible information... ...you should use https and check the certificate the first time you're in contact with the site. Even typing in the correct domain name doesn't safe you from dns spoofing.
In theory I agree with you Carsten. But practically most users will trust a SSL-site that shows the right domain name, if the browser doesn't complain about a bad certificate (most likely a lot of users are unable to verify a SSL certificate at all and -- as you said yourself -- users often tend to be "in a hurry" and forget those things). And for someone who e. g. wants to phish paypal login data, registering a punycoded domain is a lot easier and more likely than attacking the user's DNS, so while a user who doesn't verify the certificates may life happily ever after without IDN support, chances that with IDN enabled he won't are IMO pretty good. I think I made my myself clear, but I'm no Gentoo developer so the decision is not mine to make. However since Gentoo claims to be about choice, it really would be nice if the users who don't want IDN for the argued reasons could deactive it somehow, optimally by introducing an idn or non-idn keyword to the kdelibs ebuild, but personally I'd be perfectly happy with an advice on how to disable it "by hand".
@ comment #10: previously there were no RDEPEND on net-dns/libidn in kdelibs, so you had to manually install libidn to get IDN support in KDE.
Comment #10. the lack of the choose to enable/disable the use of libidn in kdelibs is a fixable issue. We can add an use flag and this will bring to a little upstream change to the configure script. I'm trying to do more of these changed in bug #81966. I'll now make also the use of libidn selectable and post a patch to kdelibs and to the ebuild in that bug report. Then this night I'll commit it upstream.
Simone, how are you going to inform KDE users of the security implications by enabling IDN?
>since Gentoo claims to be about choice A phrase repeated too often. The increasing number of use flags and other ideas like "package.env" have also negative aspects, since up to now we have only insufficient tools to handle the complexity properly. I'm not against having a idn use flag, but I fear it will users give a false sense of security. It is also not only a KDE problem. Do we have to warn not to use net-im/jabberd, too? What about Opera? Afaik they officially stated to conform to the standard and doesn't want to do something about it. What about other packages? Sune: If we do something, then the whole portage tree should be scanned and, idn disabled by default and packages where we can't disable idn, should be hard masked, imho. A GLSA has to follow. It's not serious to say there is a problem, but we don't care for you, unless you're interested in the topic dear user. I for one still think the problem that you can be tricked is inherent to the web and there should be (commercial) certificates, issued by trust centers, which can be held liable, if they give their certs to crooks. If a user doesn't care about it, he deserves it to pay for his stupidity.
Carlo, I agree. Placing in upstream for now. Upstream bug is currently waiting for Safair/Opera.
My 2 cents : 1- IDN is just one part of possible homograph attacks, and the simplest to filter at registrar level 2- Nothing we can do will prevent lusers from following links to paypa1.com or YAH00.com or washington-mutual.com... 3- We shouldn't do more than what upstream does on the subject. Firefox will disable IDN support by default, then we will. 4- Like spoofing issues, I tend to consider homographs issues a minor problem, heavily relying on user non-education, so I won't bother too much about it. So we'll wait for upstream here, like we do for Mozilla and Opera.
Created attachment 53634 [details, diff] post-3.3.2-kdelibs-idn.patch herd: As stated in http://bugs.gentoo.org/show_bug.cgi?id=83814#c14 the 3.3.2 patch provided by upstream does not apply. This one is correct in the sense that kdelibs compiles, but konqueror is just broken with idn's. My crappy box cringes and I'd like if someone who is familar with the kde framework would have a look at it. Thanks.
CC'ing random KDE guy. cryos is the random victim, please take this for a testdrive. carlo if you want other testers please CC them.
That patch works great here on amd64. Before the test page worked and I couldn't tell, after the link fails. The page doesn't work in KDE 3.4 either.
The correct patch should be here: ftp://ftp.kde.org/pub/kde/security_patches/post-3.3.2-kdelibs-idn-2.patch Will this need a kdelibs-3.3.2-r8, after -r7 for bug 83814?
Gregorio: The patch is incorrect and yes it'll need another revision.
KDE any progress on this one?
carlo: the patch in comment 24 (post-3.3.2-kdelibs-idn-2.patch) seems the official upstream solution, which corrects the bogus one (post-3.3.2-kdelibs-idn.patch), or I'm missing something?
Gregorio: first kde.org patch (against branch) --- kdecore/network/kresolver.cpp 13 Jan 2005 19:10:37 -0000 1.32.2.8 +++ kdecore/network/kresolver.cpp 16 Mar 2005 04:03:06 -0000 1.32.2.11 vs mine --- kdecore/network/kresolver.cpp 2004/10/30 02:46:23 1.32.2.5 +++ kdecore/network/kresolver.cpp 2005/03/03 12:35:36 1.32.2.10 vs second kde.org patch --- kdecore/network/kresolver.cpp 25 Feb 2005 12:27:55 -0000 1.32.2.9 +++ kdecore/network/kresolver.cpp 3 Mar 2005 12:35:36 -0000 1.32.2.10 As you can see, all different. Iirc I tested the second patch kde.org patch and it did not work for me. Unfortunately kde.org cvs->svn conversion is going on and not reachable for me right now... Sorry that it takes that long, but I don't have that much time left for Gentoo atm. I'll try to have a look at it within the next 2 or three days.
What I had as second upstream patch was something different - it does indeed work. I'm still a bit puzzled that the error message doesn't loose a word about idn/homomorphic attacks though. I think fixing this together with Bug 88862 should suffice.
KDE any new status on this one?
With the latest kdelibs revision bump, this bug is fixed, too.
Thanks carlo. Default Configs -> Closing without GLSA.
