MAR
16
2005

Security: Advisories for DCOP and Konqueror

Three
KDE security advisories
have been released today that address minor problems that were brought to the attention of the KDE security team over the last few months. All these issues have been fixed in KDE 3.4, for older KDE versions patches are available.

  1. The SUSE security team alerted us that a malicious local user can

    lock up the dcopserver of arbitrary other users on the same machine

    by stalling the DCOP authentication process.
  2. A problem that affected all browsers that support International Domain Names (IDN) and that has been widely publicized already is that the IDN support makes
    Konqueror

    vulnerable to a phishing technique known as a Homograph attack
    . This problem has been solved by only supporting IDN in those domains for which the domain registrar
    enforces a homographic character policy.

  3. The dcopidlng script is vulnerable to symlink attacks
    , potentially
    allowing a malicious local user to overwrite arbitrary files of a user when
    the script is run on behalf of that user. This only affects users
    who compile KDE or KDE applications themselves.

Comments

Is problem No 2 really a "minor" problem?

These homographic phishing attacks can have very bad consequences, and since everybody seems to talk about them they are also known to the bad guys. Since this is not a sophisticated high tech attack, the geeks among us tend to take security issues like that not too serious, but for the simple desktop user it doesn't matter if he gets a victim of a clever or a stupid hacker.

I also don't understand the suggested solution. Can one explain in more details why this is a secure way to close that problem?


By furanku at Wed, 2005/03/16 - 6:00am

From the Security Advisory (first link):

For KDE 3.4 KDE and the Konqueror webbrowser have adopted a
whitelist of domains for which IDN is safe to use because the
registrar for these domains has implemented anti-homographic
character policies or otherwise limited the available set of
characters to prevent spoofing.


By ac at Wed, 2005/03/16 - 6:00am

I know this idn phishing attacks are hard to prevent, but isn't that just saying "We're not responsible anymore!", or a bit more exaggerated "Closing holes by blaming someone else"?


By furanku at Wed, 2005/03/16 - 6:00am

Sure, but the thing is, it's very easy for e.g. the german .de registrar to limit names to something like [a-z]+[öüß] because that is what people in germany are interested in, registering domain names that match names as they are commonly used in their language.

The french .fr registrar may want to do the same for [a-z]+[éèàç] It's quite unlikely that someone in france will want to use a 'ß' in its name.

So if the registrars take the responsibility to limit registrations to a sensible subset, the problem is quite easy to solve, while it is virtually impossible to solve at the broswer level alone.


By Waldo Bastian at Wed, 2005/03/16 - 6:00am

OK, this is not KDE specific anymore, but I don't think that is a practical solution. If I just think of immigrants, who want a homepage with a proper spelling of their name, international companies with branches in foreign countries, fan club sites for foreign artists, common foreign words with accents in languages which don't use that accent, etc ...

In summary: The world is too small nowadays to restrict .de websites to [a-z]+[äöüß]. What about all the Renée's who want a homepage, what about www.citroën.de, www.björk-fanclub.fr, ...


By furanku at Thu, 2005/03/17 - 6:00am

URL should ideally be easily enterable by citizens of the specific country's keyboard's standard layout. I'd consider the resulting restrictions 'natural', and the decision to handle this with a whitelist on KDE's site is an excellent solution to this problem.


By ac at Thu, 2005/03/17 - 6:00am

OK, thanks for the information!

I still think that companies will use automatic redirection (www.citroen.de -> www.citroën.de) to keep their holy corporate identity. But time will tell if the whitlisting will be effective, and hopfully I'm wrong ;)


By furanku at Fri, 2005/03/18 - 6:00am

The solution basically delegates the responsibility to the domain registrar for a given TLD to make sure that nobody can registrate a domain name under that TLD that is visually similar to another domain name. IDN will only be enabled for TLDs with registrars that accept that responsibility.


By Waldo Bastian at Wed, 2005/03/16 - 6:00am

and how do you know that the tld registrar has done so?
and how can you be sure that he actually does, instead of just pretending?


By Mathias at Wed, 2005/03/16 - 6:00am

> and how do you know that the tld registrar has done so?

User feedback and what Opera uses.

> and how can you be sure that he actually does, instead of just pretending?

User feedback


By Anonymous at Thu, 2005/03/17 - 6:00am

The similar-looking IDN characters isn't any different than 0 and O looking similar or, for that matter, l and 1. It's an issue, but with many benefits and no real way to get around it.


By Keith at Wed, 2005/03/16 - 6:00am

No-- it's less like 0 and O and more like 0 and 0.

An example: http://www.shmoo.com/idn/


By jaykayess at Wed, 2005/03/16 - 6:00am

Right. And that's why KDE no longer supports IDNs for .com domains.


By Ingo Klöcker at Wed, 2005/03/16 - 6:00am

One of the biggest arguments out there against IDN is the Phishing argument. This has now largely been negated by ICANN banning registeration of mixed character scripts that are likely to cause confusion.

However, another side of the story has been put. It is clear that many words in local characters have multiple representations when transliterated, often with more than one system, into Latin Characters. Each of these ambiguities offers an opportunity for a Phisher to conduct his Scam. Unlike the problem of eliminating the use of rogue cyrillics in Latin scripts, I see no easy solution to this problem, as each of the transliterations are in a single script and therefore legitimate. Indeed, each could have legitimate usuage, but surely often won't.

The argument therefore develops into the imperative of introducing IDN to prevent Phishing Scams in Asia. Without IDN, it is likely that the confusion over how to transliterate will result in a Pandemic of Scamming, the scale of which will be unprecidented! I feel that we should no longer be silent on the issue of Phishing as IDN undoubtedly will hold the moral high ground on this issue.


By David Wrixon at Sun, 2005/11/20 - 6:00am

Would it be possible to highlight IDN characters in Konqui's status bar? Then at least we could see whether an a is really an a or bait on the end of a fishing line.


By Flitcraft at Wed, 2005/03/16 - 6:00am

Um, that would hardly stop phishing unless you happened to know what the highlighted characters meant.


By Ian Monroe at Wed, 2005/03/16 - 6:00am

True, but it might prevent clicking on a link that looks innocuous at first glance.


By Flitcraft at Wed, 2005/03/16 - 6:00am

I really like the idea of Konqi giving some sort of visual feedback like that. Maybe accompanied by a status bar icon like the lock, with a popup text notification on mousever of the icon that would detail the potential risk.

Mark.


By Mark Taff at Fri, 2005/03/18 - 6:00am

KDE 3.4 was released today, see slashdot for more info.


By Iuri Fiedoruk at Wed, 2005/03/16 - 6:00am