Sunday, December 22, 2024
Open SourceSecurityTechnologyUbuntu

KDE issues security advisory for HTTPS KIO Slave

The KDE project has issued a security advisory for the HTTPS KIO Slave yesterday. KIO is a KDE-specific technology which allows applications to transparently access any content as if it was a file, through the use of helper applications (“slaves”). For example it is possible to access SMB shares through the smb:/ slave, or even read man pages in Konqueror through the man:/ slaves.

The HTTPS Slave supports the autoconfiguration of web proxies through the Web Proxy Autodiscovery Protocol (WPAD) and is set to do so by default. WPAD uses a variety of methods (DHCP, “well known” DNS entries, Service Location Protocols) to check for the existence of a local, network-specific Proxy Auto-Config (PAC) file. A PAC file is a piece of JavaScript which contains a function called FindProxyForURL. The requested URL and Host are passed to this function, and the function can then perform JavaScript magic to decide if the requested address should be accessed directly or through a Proxy.

Here’s an example:

function FindProxyForURL(url, host) {
    if(isPlainHostName(host) ||
        shExpMatch(host, "*.local") ||
        isInNet(dnsResolve(host), "192.168.0.0",  "255.255.0.0") ||
        isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0"))
        return "DIRECT";

    if(dnsDomainIs(host, "www.lieberbiber.de") ||
        shExpMatch(host, "(*.lieberbiber.de|lieberbiber.de)"))
        return "DIRECT"

    return "PROXY 192.168.1.10:8080; PROXY 192.168.1.20:8080";
}

This function would return two proxies on the local network, except when the address is already on the local network or goes to my webserver.

The vulnerability here is that the full URL with all parameters (including usernames, passwords etc.) was passed to the FindProxyForURL function. A malicius attacker could manipulate the local network and distribute a PAC file which then leaks the full URL (e.g. over the network), even though HTTPS is supposed to protect the URL. The issue has been fixed for HTTPS in two commits (here and here). There is no fix for HTTP as it is unencrypted and the proxy can always see the full URL anyways.

I wonder how many browsers and HTTPS libraries have similar flaws.

Leave a Reply

Your email address will not be published. Required fields are marked *