From: Tim Brown To: Tomas Hoger Subject: Re: [oss-security] CVE request - asterisk, python-markdown, jetty, kde Date: Fri, 30 Oct 2009 10:50:52 +0000 User-Agent: KMail/1.9.9 References: <200910292208.22523.tmb@65535.com> <20091030104113.2dc848d5@redhat.com> In-Reply-To: <20091030104113.2dc848d5@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910301050.54101.tmb@65535.com> On Friday 30 October 2009 09:41:13 Tomas Hoger wrote: > Hi Tim! > > On Thu, 29 Oct 2009 22:08:20 +0000 Tim Brown 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: - fixed in 3.5.10 * man: * info:/dir/ * perldoc: * 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):

KMail Test

> > * 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