[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: security vulnerability in konqueror
From:       Waldo Bastian <bastian () kde ! org>
Date:       2001-08-27 21:38:48
[Download RAW message or body]

On Saturday 25 August 2001 11:03 am, George Staikos wrote:
> I am away on vacation and didn't see any talk on the lists about this so I
> want to bring this up again.  There is a rather bad security hole in
> Konqueror.  Remote documents and http should only be allowed to redirect to
> http://, ftp://, news:// and mailto:.  (perhaps I missed one?)  Right now
> it's easy to redirect to rio://, floppy://, audiocd://, pop3://, smtp://,
> lan://, nfs://, etc.  This introduces all kinds of issues.  Dialogs could
> prompt for passwords which would be sent off to remote hosts without the
> user understanding what is really going on.  For instance, files could be
> erased from personal devices.  We don't know what kind of ioslaves people
> will write in the future too.  There should be tight restrictions on what
> is allowed for clickable links, java[script] and redirect urls.

The idea that I had was to implement a "security manager" (A singleton class) 
which needs to authorize actions that involve URLs. Something like

KSecurityManager::authorizeURL(baseURL, action, newURL)

"baseURL" would the URL describing the current resource and "action" would be 
something like "user-clicked-link", "http-redirect", "explicit-open", 
"resource-request-by-html" (e.g. image, css-thingy), 
"script-requested-by-html" (e.g. javascript)

newURL would be the requested resource.

The set of (baseURL,action) would make up the authorisation context. When we 
assign this context to a KIO::Job, the job could check, when it gets a 
redirect, authorizeURL(baseURL, "http-redirect", redirected-to-URL) but also
authorizeURL(baseURL, action, redirected-to-URL).

This way you can guarantee that an action on a protocol which wouldn't be 
allowed directly, can't be obtained by means of a URL redirection either.

I will not have any time to implement this before KDE 2.2.1 though.
(It probably needs some more thinking anyway, to make sure that it is 
foolproof.)

What are the exact implications of this vulnerability? A malicious html page 
can redirect the browser to another protocol, resulting in undesired 
read-access. Is it possible to publish the data that is being accessed in 
anyway beyond the applicatin that does the access? Can javascript do that?
It might cause problems with protocols that have side-effects on read-access 
(like the brain-dead scheme used by pop3, which encodes the command in the 
URL and then does a GET for things like deleting messages)

Cheers,
Waldo
-- 
KDE 2.2: We deliver.

[prev in list] [next in list] [prev in thread] [next in thread]