A method to bypass SSL certificate name vs. host name verification via NUL ('\0') character embedded in X509 certificate's CommonName or subjectAltName was presented at Black Hat USA 2009:
http://www.blackhat.com/html/bh-usa-09/bh-usa-09-archives.html#Marlinspike
Similar issues affects kdelibs' kssl. Problem only exists in handling of subjectAltNames, CommonNames with embedded NUL chars are handled correctly.
According to Thiago Macieira (maintainer of KDE's and Qt's SSL code), kssl is no longer used in current KDE4 versions, Qt's SSL code is used instead (which is affected by similar problem, see bug #520435).
Problem affects kdelibs 3.5.4 shipped in Red Hat Enterprise Linux 5. Versions in Red Hat Enterprise Linux 4 (3.3.1) and Red Hat Enterprise Linux 3 (3.1.3) are not affected, as they do not support subjectAltNames at all.
Unlike Qt, kssl is not prone to creation of universal MITM certificate (\0.whatever.com), as matching of '' wild card is limited to single host name component.
aRts 1.5.10 and kdelibs3 3.5.10 and earlier do not properly create temporary directories, which allows local users to hijack the IPC by pre-creating the temporary directory.
KDE kdelibs before 4.14 and kauth before 5.1 does not properly use D-Bus for communication with a polkit authority, which allows local users to bypass intended access restrictions by leveraging a PolkitUnixProcess PolkitSubject race condition via a (1) setuid process or (2) pkexec process, related to CVE-2013-4288 and "PID reuse race conditions."
It was reported [1] that when KDE encounters an "internal server error" and also prints out the URL that caused the error that it would include the username and password (if supplied) to the resource that caused the error. For instance, it would show "https://user:password@remotehost.com" or similar. This is due to kioslave/http/http.cpp using mrequest.url.url() rather than the sanitized mrequest.url.prettyUrl(). This issue is fixed in git [2].
Note that this information is printed out to the local user actively using the computer.
[1] https://bugs.kde.org/showbug.cgi?id=319428 [2] https://projects.kde.org/projects/kde/kdelibs/repository/revisions/65d736dab592bced4410ccfa4699de89f78c96ca/diff/kioslave/http/http.cpp
kio/usernotificationhandler.cpp in the POP3 kioslave in kdelibs 4.10.95 before 4.13.3 does not properly generate warning notifications, which allows man-in-the-middle attackers to obtain sensitive information via an invalid certificate.
It was reported [1] that when KDE encounters an "internal server error" and also prints out the URL that caused the error that it would include the username and password (if supplied) to the resource that caused the error. For instance, it would show "https://user:password@remotehost.com" or similar. This is due to kioslave/http/http.cpp using mrequest.url.url() rather than the sanitized mrequest.url.prettyUrl(). This issue is fixed in git [2].
Note that this information is printed out to the local user actively using the computer.
[1] https://bugs.kde.org/showbug.cgi?id=319428 [2] https://projects.kde.org/projects/kde/kdelibs/repository/revisions/65d736dab592bced4410ccfa4699de89f78c96ca/diff/kioslave/http/http.cpp