KDE recently fixed an issue in the code checking host names of the
server SSL certificates. Previously, it accepted certificate as valid
for the site if it was issued for the user-specified host name, or if
it was issued for an IP address to which user-specified host name
An attacker able to get an SSL certificate form a trusted CA issued for
an attacker-controlled IP address could perform a MITM attack, if they
were also able to hijack victim's DNS to resolve host names to the
Fixed upstream in:
Patch is included in kdelibs 4.6.1.
Maintainers, is it OK to stabilize >=kde-base/kdelibs-4.6.1? If so, which version?
We discussed this yesterday and 4.6.1 is way to buggy (even with annoying regressions to 4.6.0) for stabilization. (Currently 4.6.2 is our planned candidate.)
I just committed an UNTESTED backport of the patch in kdelibs-4.4.5-r3. The code has not changed much, so this should work in theory. The problem is, I cannot even build-test it. So, for now NO KEYWORDS yet.
@security,kde: anyone of you running kde-4.4: please test the ebuild. If it builds fine, add all arches from -r2 back as ~arch. Afterwards we can request fast stabilization on relevant arches.
@kde: time to kill 4.5?
(In reply to comment #2)
> @security,kde: anyone of you running kde-4.4: please test the ebuild. If it
> builds fine, add all arches from -r2 back as ~arch. Afterwards we can request
> fast stabilization on relevant arches.
It seems you're mistaking Security for an ebuild testing team.
> @kde: time to kill 4.5?
That discussion should not take place on this very bug.
(In reply to comment #3)
> It seems you're mistaking Security for an ebuild testing team.
It seems I'm mistaking Security for a team interested in fixing security issues.
(In reply to comment #4)
> (In reply to comment #3)
> > It seems you're mistaking Security for an ebuild testing team.
> It seems I'm mistaking Security for a team interested in fixing security
No, you got that one right.
Providing updated, working ebuilds ready for arches to test is *YOUR* responsibility though.
(In reply to comment #5)
> > It seems I'm mistaking Security for a team interested in fixing security
> > issues.
> No, you got that one right.
> Providing updated, working ebuilds ready for arches to test is *YOUR*
> responsibility though.
Oh please cut the whatever. Once your GLSA's are as current and updated as this ebuild we can discuss that again.
Is it too much to ask for a little bit of cooperation? Most of the kde team is running 4.6 by now, and cannot easily test the 4.4 ebuilds since all the required dependencies are long gone from their systems. [*] And I can imagine it takes a lot less work to type "ebuild kdelibs-4.4.5-r3.ebuild install" and report on its result 1-2 hours later than to read and digest the daily flood of security advisories.
[*] Which is why we have even considered forming a separate kde-stable team. Only because kde-4.6 stabilization is now slowly coming closer we have abandoned that plan.
(In reply to comment #6)
> (In reply to comment #5)
> > > It seems I'm mistaking Security for a team interested in fixing security
> > > issues.
> > No, you got that one right.
> > Providing updated, working ebuilds ready for arches to test is *YOUR*
> > responsibility though.
> Oh please cut the whatever. Once your GLSA's are as current and updated as this
> ebuild we can discuss that again.
If you actually knew the amount of work that's in one of these advisories, you wouldn't talk like that.
> Is it too much to ask for a little bit of cooperation?
> Most of the kde team is
> running 4.6 by now, and cannot easily test the 4.4 ebuilds since all the
> required dependencies are long gone from their systems.
That's exactly my point. All of the 42 billion Gentoo KDE devs seem to use the fancy new stuff, so you think you can dump the unpleasant work of testing your old stable stuff to us? Forget it.
(This makes you referring to the GLSA situation even more bizarre)
EOD. From here on, let's focus on getting the bug fixed for stable users, which is my main interest. I hope that you contribute your part to that and we'll see to do the same.
Doesn't compile on my ~amd64 machine at work (which is still on kde-4.4.5):
[ 40%] Building CXX object kio/CMakeFiles/kio.dir/kio/tcpslavebase.o
/var/tmp/portage/kde-base/kdelibs-4.4.5-r3/work/kdelibs-4.4.5/kio/kio/tcpslavebase.cpp: In member function ‘KIO::TCPSlaveBase::SslResult KIO::TCPSlaveBase::startTLSInternal(uint)’:
/var/tmp/portage/kde-base/kdelibs-4.4.5-r3/work/kdelibs-4.4.5/kio/kio/tcpslavebase.cpp:514:43: error: ‘isMatchingHostname’ was not declared in this scope
make: *** [kio/CMakeFiles/kio.dir/kio/tcpslavebase.o] Error 1
make: *** [kio/CMakeFiles/kio.dir/all] Error 2
make: *** [all] Error 2
# emerge --info kdelibs
Portage 2.2.0_alpha26 (default/linux/amd64/10.0, gcc-4.5.2, glibc-2.11.3-r0, 188.8.131.52 x86_64)
System uname: Linux-184.108.40.206-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9550_@_2.83GHz-with-gentoo-2.0.1
Timestamp of tree: Wed, 09 Mar 2011 14:15:01 +0000
dev-lang/python: 2.7.1-r1, 3.1.3-r1
sys-devel/autoconf: 2.13, 2.68
sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1
sys-devel/gcc: 4.4.5, 4.5.2
virtual/os-headers: 220.127.116.11 (sys-kernel/linux-headers)
Repositories: gentoo poly-c
ACCEPT_LICENSE="* -@EULA AdobeFlash-10.1 dlj-1.1 PUEL"
CFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer -finline-functions"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/X11/Sessions /etc/X11/app-defaults /etc/X11/xinit /etc/adobe /etc/bash_completion.d /etc/bonobo-activation /etc/ca-certificates.conf /etc/cups /etc/dbus-1 /etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/fish /etc/fonts /etc/fonts/fonts.conf /etc/foomatic /etc/gconf /etc/gentoo-release /etc/gimp /etc/gnome-vfs-2.0 /etc/gtk /etc/gtk-2.0 /etc/hotplug /etc/hotplug.d /etc/htdig /etc/imlib /etc/init.d /etc/iproute2 /etc/libgda-3.0 /etc/ntop /etc/pam.d /etc/pango /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/profile.d /etc/qt4 /etc/revdep-rebuild /etc/sandbox.d /etc/sasl2 /etc/sgml /etc/sound /etc/ssl /etc/ssmtp /etc/t1lib /etc/terminfo /etc/usb_modeswitch.d /etc/xinetd.d /etc/xml /etc/zsh"
CXXFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer -finline-functions"
EMERGE_DEFAULT_OPTS="--alphabetical --with-bdeps=y --jobs=1 --keep-going"
FEATURES="assume-digests binpkg-logs collision-protect distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -Wl,--as-needed"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
USE="3dnow 3dnowext X a52 aac acpi alsa amd64 berkdb bzip2 caps cdda cdparanoia cdr cli cracklib crypt cups cxx dbus dvd dvdr dvdread encode fam ffmpeg flac gdbm gif gmp gnutls gpg gtk iconv idn imagemagick imlib jpeg jpeg2k kde kdehiddenvisibility lame mjpeg mmx mmxext modules mp3 mpeg mudflap multilib ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcre png pppd qt3support qt4 quicktime readline rtmp sdl session silc slang smp sse sse2 ssl svg sysfs theora threads tiff truetype twolame unicode vcd vorbis vpx x264 xcb xcomposite xinerama xml xorg xulrunner xv xvid zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LINGUAS="de en" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby19" SANE_BACKENDS="hp" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
kde-base/kdelibs-4.4.5-r2 was built with the following:
USE="3dnow -acl alsa (-altivec) (-aqua) -bindist bzip2 -debug -doc fam handbook jpeg2k (-kdeenablefinal) (-kdeprefix) -kerberos -lzma mmx (multilib) nls -openexr opengl -policykit semantic-desktop -spell sse sse2 ssl -test -zeroconf"
+ 10 Mar 2011; Lars Wendler <email@example.com>
+ Added fixed 4.4.5-hostname.patch (with kind permission from tampakrap).
+ 10 Mar 2011; Andreas K. Huettel <firstname.lastname@example.org>
+ Keywords added, thanks to Poly-C for testing
Arches please test and mark stable kde-base/kdelibs-4.4.5-r3
Target "amd64 ~arm ppc ~ppc64 x86 ~x86-fbsd ~amd64-linux ~x86-linux",
i.e. stabilization on amd64, ppc, x86
This fixes a security bug.
amd64 appears fine. compile with no problems.
amd64 done. Thanks Agostino
x86 stable. IMHO if you need testers for stable kde patches it is ok to ask the arch teams (asking me for x86 is OK at least). We are running stable boxes for testing purposes anyway.
ppc stable, last arch done
Thanks, everyone. GLSA Vote: no.
Nothing to do for kde here anymore.
kio/kio/tcpslavebase.cpp in KDE KSSL in kdelibs before 4.6.1 does not
properly verify that the server hostname matches the domain name of the
subject of an X.509 certificate, which allows man-in-the-middle attackers to
spoof arbitrary SSL servers via a certificate issued by a legitimate
Certification Authority for an IP address, a different vulnerability than
Vote: YES. Added to pending GLSA request.
This issue was resolved and addressed in
GLSA 201406-34 at http://security.gentoo.org/glsa/glsa-201406-34.xml
by GLSA coordinator Mikle Kolyada (Zlogene).