Re: CVE-2016-7966 kcoreaddons

[Moritz Mühlenhoff]

On Thu, Oct 13, 2016 at 12:15:01PM +0200, Sandro Knauß wrote:
> Hey,
> 
> The description 
> https://www.kde.org/info/security/advisory-20161006-1.txt do not describe all 
> patches that are needed to fix the CVE (at the moment).
> 
> The additional patches are not part of KDE Frameworks 5.27, so they need to 
> be 
> applied for KF 5.27:
> 5e13d2439dbf540fdc840f0b0ab5b3ebf6642c6a (0004-Display-bad-url.patch)
> a06cef31cc4c908bc9b76bd9d103fe9c60e0953f (0003-Add-more-autotests.patch)
> 
> (the first two will be included in KF 5.27).
> 
> The fixed version is 5.26.0-3 (sid only - already uploaded). I'll test if we 
> need these patches also for stable inside kdepimlibs.

Ok, please let us know once you know more. Scott Kitterman has already sent an
update for kdepimlibs (attached).

Cheers,
Moritz



diff -Nru kdepimlibs-4.14.2/debian/changelog kdepimlibs-4.14.2/debian/changelog
--- kdepimlibs-4.14.2/debian/changelog  2014-11-16 22:38:20.0 -0500
+++ kdepimlibs-4.14.2/debian/changelog  2016-10-12 12:21:04.0 -0400
@@ -1,3 +1,12 @@
+kdepimlibs (4:4.14.2-2+deb8u1) jessie-security; urgency=high
+
+  * Team upload.
+  * CVE-2016-7966 KMail: HTML injection in plain text viewer (Closes: #840546)
+- Avoid transforming as a url in plain text mode when there is a quote
+- Add debian/patches/CVE-2016-7966.diff from upstream
+
+ -- Scott Kitterman   Wed, 12 Oct 2016 12:20:26 -0400
+
 kdepimlibs (4:4.14.2-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru kdepimlibs-4.14.2/debian/patches/CVE-2016-7966.diff 
kdepimlibs-4.14.2/debian/patches/CVE-2016-7966.diff
--- kdepimlibs-4.14.2/debian/patches/CVE-2016-7966.diff 1969-12-31 
19:00:00.0 -0500
+++ kdepimlibs-4.14.2/debian/patches/CVE-2016-7966.diff 2016-10-12 
11:45:54.0 -0400
@@ -0,0 +1,89 @@
+From: Montel Laurent 
+Date: Fri, 30 Sep 2016 13:55:35 +
+Subject: Backport avoid to transform as a url when we have a quote
+X-Git-Url: 
http://quickgit.kde.org/?p=kdepimlibs.git=commitdiff=176fee25ca79145ab5c8e2275d248f1a46a8d8cf
+---
+Backport avoid to transform as a url when we have a quote
+---
+
+
+--- a/kpimutils/linklocator.cpp
 b/kpimutils/linklocator.cpp
+@@ -94,6 +94,12 @@
+ }
+ 
+ QString LinkLocator::getUrl()
++{
++return getUrlAndCheckValidHref();
++}
++
++
++QString LinkLocator::getUrlAndCheckValidHref(bool *badurl)
+ {
+   QString url;
+   if ( atUrl() ) {
+@@ -129,13 +135,26 @@
+ 
+ url.reserve( maxUrlLen() );  // avoid allocs
+ int start = mPos;
++bool previousCharIsADoubleQuote = false;
+ while ( ( mPos < (int)mText.length() ) &&
+ ( mText[mPos].isPrint() || mText[mPos].isSpace() ) &&
+ ( ( afterUrl.isNull() && !mText[mPos].isSpace() ) ||
+   ( !afterUrl.isNull() && mText[mPos] != afterUrl ) ) ) {
+   if ( !mText[mPos].isSpace() ) {   // skip whitespace
+-url.append( mText[mPos] );
+-if ( url.length() > maxUrlLen() ) {
++  if (mText[mPos] == QLatin1Char('>') && previousCharIsADoubleQuote) {
++  //it's an invalid url
++  if (badurl) {
++  *badurl = true;
++  }
++  return QString();
++  }
++  if (mText[mPos] == QLatin1Char('"')) {
++  previousCharIsADoubleQuote = true;
++  } else {
++  previousCharIsADoubleQuote = false;
++  }
++  url.append( mText[mPos] );
++  if ( url.length() > maxUrlLen() ) {
+   break;
+ }
+   }
+@@ -367,7 +386,12 @@
+ } else {
+   const int start = locator.mPos;
+   if ( !( flags & IgnoreUrls ) ) {
+-str = locator.getUrl();
++bool badUrl = false;
++str = locator.getUrlAndCheckValidHref();
++if (badUrl) {
++return locator.mText;
++}
++
+ if ( !str.isEmpty() ) {
+   QString hyperlink;
+   if ( str.left( 4 ) == QLatin1String("www.") ) {
+
+--- a/kpimutils/linklocator.h
 b/kpimutils/linklocator.h
+@@ -107,6 +107,7 @@
+   @return The URL at the current scan position, or an empty string.
+ */
+ QString getUrl();
++QString getUrlAndCheckValidHref(bool *badurl = 0);
+ 
+ /**
+   Attempts to grab an email address. If there is an @ symbol at the
+@@ -155,7 +156,7 @@
+ */
+ static QString pngToDataUrl( const QString & iconPath );
+ 
+-  protected:
++protected:
+ /**
+   The plaintext string being scanned for URLs and email addresses.
+ */
+
+
diff -Nru kdepimlibs-4.14.2/debian/patches/series 
kdepimlibs-4.14.2/debian/patches/series
--- kdepimlibs-4.14.2/debian/patches/series 2014-11-16 22:40:13.0 
-0500
+++ kdepimlibs-4.14.2/debian/patches/series 2016-10-12 11:46:32.0 
-0400
@@ -1,3 +1,4 @@
 add_soname_to_xsd_file
 sslv2_disabled.patch
 tlscancelled.patch
+CVE-2016-7966.diff
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Qt4's Webkit in Stretch

[Moritz Mühlenhoff]

On Fri, Jan 22, 2016 at 05:16:26PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Hi everyone! I would like to discuss the current situation for Qt4's Webkit 
> in 
> Stretch.
> 
> Let me first start with some facts:
> 
> = Facts =
> 
> - Both Qt4 and (by inclusion) Qt4's webkit are no longer supported upstream.
> 
> - If a security bug appears in Qt4 during Stretch's lifetime I'm pretty sure 
> we will be able to come up with a patch. There is too much people depending 
> on 
> it out there so this won't be a problem for Stretch.
> 
> - For Qt4's webkit the situation might probably be the other way around. 
> Actually we might already have (quite some?) security bugs out there.
> 
> = Removal efforts and options =
> 
> So last year we started to work on removing it [removal]. Progress is sadly 
> far from good. We still have quite a lot of apps depending on qebkit in order 
> to show things like doc. Most of them do not use it for web browsing.
> 
> [removal] 
> 
> This has been discussed in the Qt/KDE team quite a lot of times with 
> different 
> opinions. For what I could gather the possible options are:
> 
> (keep) Keep Qt4's webkit as it is in Stretch and warn users that they will 
> get 
> *no* security support.
> 
> (removeintesting) Remove Qt4's webkit from testing, file an RC bug against it 
> so it doesn't transition and let rdeps be removed from testing until they 
> switch. Of course we will need the RT's approval for this.
> 
> (totalremove) Remove Qt4's webkit from the archive together with it's rdeps 
> (or leave the rdeps RC buggy in unstable).
> 
> Does anyone has a better idea?
> 
> = What do we do? =
> 
> If we take the (keep) option we need a good way to ensure users get the fact.
> 
> If we go for any of the other two options we will need the RT/FTP team to ACK 
> the move.
> 
> So I would really like to hear the opinions of people in both teams. If you 
> really think a certain way forward should be taken please speak now.
> 
> Kinds regards, Lisandro.

>From my point of view, qtwebkit has never been covered by security support 
>upstream
and in Debian. We even document this in the release notes (and for several 
releases
already): 
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security

So (keep) is the status quo and we can keep just as well maintain it for 
stretch.

Cheers,
Moritz



-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk