Three security advisories have been issued today for KDE.
The first advisory concerns the unsafe handling of KDE's temporary directory in certain circumstances.
The second advisory relates to the unsafe creation of temporary files by KDE 3.2.x's
dcopserver.
The third advisory is about a frame injection vulnerability in Konqueror as earlier reported by
Heise Online
and
Secunia.
Distributions are expected to have updated binary packages available shortly. All issues mentioned above have also been fixed in the
KDE 3.3 Release Candidate 2
that was
announced yesterday. The final release of KDE 3.3 is expected later this month.
Dot Categories:
Comments
These bugs still have the status of new:
a)Browser Frame Injection Vulnerability
http://bugs.kde.org/show_bug.cgi?id=84352
b)security vulnerability: URL-Spoofing as shown on heise.de
http://bugs.kde.org/show_bug.cgi?id=83407
83407 has not been fixed. The impact of it is limited because you
can achieve the same effect when you use javascript to set the statusbar text on hover.
Is there a specialized KDe security project that reviews code of critical application? Securtiy reviews are of great importance and developers often don't find their own errors.
There is http://www.kde.org/info/security/ to where people are always welcome to report security issues they found.
With the number of commits that go into KDE, security reviews are necessarily ongoing. There are a number of things that are in place to attempt to catch the various errors:
Commits are available by email, hence developers watch what is going in and comment on security issues. This happens regularly with khtml.
Calls to library routines that are potential problems are flagged on the email list as potentially unsafe, making it easy for others to check.
Some developers have private review arrangements in place.
Derek
> Some developers have private review arrangements in place.
What does that mean?
Private as opposed to public, on mailing lists etc.
Watching the commit logs over a long period, it is obvious that many developers have people they work with, who test or review what they are doing. They are unnamed, and the conversations are private, ie. email as opposed to mailing list.
Derek
Ah, thanks for the clarification.
Although there is a continuous review of changes, there is currently no structured review process for applications as a whole. Especially when new applications are added to KDE CVS that proves to be a problem, because such new applications often contain unsafe constructions.
With the release of KDE 3.1 we have done a code review of all of CVS looking for uses of certain constructions that have turned out to be problematic. That might offer a good basis to start from when starting an audit process.
Ideally we would have a group of people that actively maintains a list of problematic constructions and that performs audits on an application by application basis and documents the results.
> Ideally we would have a group of people that actively maintains a list of problematic constructions and that performs audits on an application by application basis and documents the results.
I hear that the SUSE Security Team does that occasionally, eg they looked at the instant messengers Kopete and Gaim - well, you know the not so favorable result for Gaim (http://www.heise.de/newsticker/meldung/49837).