Robert Swiecki has reported a vulnerability in Konqueror, which can be exploited by malicious people to conduct spoofing attacks. For more information: SA26074 (http://secunia.com/advisories/26074) this is the same than the opera vuln. The vulnerability is reported in version 3.5.7. Other versions may also be affected. Solution: Fixed in the SVN repository.
pulling in herd. Kde, please advise.
Created attachment 125218 [details, diff] konqueror-3.5.7-location.patch Here is the patch - I think it will apply to all versions of konqueror. We are working to stabilise KDE 3.5.7 but it shouldn't be much trouble to patch 3.5.5 too in order to stabilise sooner.
ok, so how do you want to proceed? do you want to stabilize 3.5.7 or patch 3.5.5? from a security pov, this is not a critical vuln so if you're too busy to patch 3.5.5, I think we can wait for 3.5.7 to go stable.
KDE 3.5.7 is very close to being ready to mark stable. I will apply the patch there and we will stabilise. Should be good to go over the weekend or early next week unless something crops up.
kde-base/konqueror-3.5.7-r1 and kde-base/kdebase-3.5.7-r2 have the patch applied and should fix this issue. Please test and confirm - these will be stabilised with KDE 3.5.7.
Thanks Marcus. Arches, please test and mark stable konqueror-3.5.7-r1. Target keywords are: "alpha amd64 ia64 ppc ppc64 sparc x86 ~x86-fbsd"
Um, no Pierre-Yves. This version definitely does not go stable now.
Waiting for 3.5.7 stable marking and CC'ing kde herd again.
There are actually two issues. This bug only seems (at the moment) to address the first. See http://seclists.org/fulldisclosure/2007/Aug/0085.html as a references. The second issue (http://alt.swiecki.net/konq3.html) should be investigated. the author claims he can reproduce on 3.5.x, but i don't have anything after 3.4 with which to test and it doesn't seem to cause a problem on 3.4 By the way, I've requested CVEs for these issues. They should be assigned... soon?
Er, I got those backwards. The above patch tries to address the second, but not the first.
Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4224 Reference: FULLDISC:20070806 Konqueror: URL address bar spoofing vulnerabilities Reference: URL:http://lists.grok.org.uk/pipermail/full-disclosure/2007-August/065101.html KDE Konqueror 3.5.7 allows remote attackers to spoof the URL address bar by calling setInterval with a small interval and changing the window.location property. ====================================================== Name: CVE-2007-4225 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4225 Reference: FULLDISC:20070806 Konqueror: URL address bar spoofing vulnerabilities Reference: URL:http://lists.grok.org.uk/pipermail/full-disclosure/2007-August/065101.html Visual truncation vulnerability in KDE Konqueror 3.5.7 allows remote attackers to spoof the URL address bar via an http URI with a large amount of whitespace in the user/password portion.
There are actually three distinct bugs: 1) Address bar URI spoofing using URLs containing spaces; the fake URI is after the spaces. Now fixed (by displaying the start of the URI and not the end). 2) URI spoofing using setInterval (http://alt.swiecki.net/konq2.html). Not fixed in Gentoo as far as I know. I assume http://websvn.kde.org/?view=rev&revision=698562 is intended to fix this. 3) URI spoofing via http URIs with a username containing lots of trailing spaces (http://alt.swiecki.net/konq3.html). Only works properly on versions of Konqueror that have the fix for (1). Not fixed as far as I know.
stabilization has been done with the others kde apps. Time for glsa decision here. I tend to vote Yes.
I vote YES too.
(In reply to comment #13) > stabilization has been done with the others kde apps. > Time for glsa decision here. I tend to vote Yes. Sorry, Pierre-Yves, but comment #12 is basically correct. This issue is not yet completely resolved and upstream is still working on it. The attached patch is incomplete. Please stand by.
Resetting status to upstream to get the remaining issues fixed.
Upstream has fixed this issue which is in turn fixed in the following package revisions: kde-base/kdelibs-3.5.7-r3 kde-base/kdebase-3.5.7-r4 kde-base/konqueror-3.5.7-r3 These should be stabilised ASAP. cc'ing arch teams.
ppc64 stable
alpha/ia64/x86 stable
Stable for HPPA.
Marked stable on amd64.
ppc stable
kde-base/kdelibs-3.5.7-r3 USE="acl branding fam tiff -alsa -arts -avahi -cups -debug -doc -jpeg2k -kdeenablefinal (-kdehiddenvisibility) -kerberos -legacyssl -lua -openexr -spell -utempter -xinerama" 1. Emerges on SPARC. 2. No collisions. 3. Test phase disabled by the ebuild. kde-base/kdebase-3.5.7-r4 USE="branding hal opengl pam -arts -cups -debug -ieee1394 (-java) -kdeenablefinal (-kdehiddenvisibility) -ldap (-lm_sensors) -logitech-mouse -openexr -samba -xcomposite -xinerama -xscreensaver" 1. Emerges on SPARC. 2. No collisions. 3. Test phase ok. kde-base/konqueror-3.5.7-r3 USE="branding -arts -debug (-java) -kdeenablefinal (-kdehiddenvisibility) -xinerama" 1. Emerges on SPARC. 2. No collisions. 3. Test phase ok. 4. Works - also tested with the rdep: kde-base/konq-plugins. Portage 2.1.3.9 (default-linux/sparc/sparc64/2007.0, gcc-4.1.2, glibc-2.5-r4, 2.6.22-gentoo-r5 sparc64) ================================================================= System uname: 2.6.22-gentoo-r5 sparc64 sun4u Timestamp of tree: Sat, 22 Sep 2007 08:20:01 +0000 app-shells/bash: 3.2_p17 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.7.9-r1, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="sparc" CBUILD="sparc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=ultrasparc -pipe" CHOST="sparc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/init.d /etc/pam.d /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -mcpu=ultrasparc -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="-k" FEATURES="ccache collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="ftp://mirrors1.netvisao.pt/gentoo http://darkstar.ist.utl.pt/pub/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X acl bash-completion bitmap-fonts branding bzip2 cli cracklib crypt dbus dri fortran gdbm gif gnome gtk hal iconv ipv6 isdnlog jpeg midi mudflap ncurses nptl nptlonly offensive opengl openmp pam pcre perl png postgres ppds pppd python readline reflection session sparc spl ssl svg tcpd test tiff truetype truetype-fonts type1-fonts xml xorg xv zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="sunffb" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
sparc stable, thanks Tiago
time to vote first. I tend to vote no.
I tend to vote NO.
Username shortening patch breaks kwallet compatibility for legitimate authentication URLs with long usernames (e.g. ftp://thisisalongusername@domain.dom). Work around seems to be to remap username and password for abbreviated URL. Still wouldn't work in some unusual cases, e.g.: ftp://longusernameoneforsomeone@domain.dom ftp://longusernametwoforsomeone@domain.dom
I vote no too, very minor security impact. Closing with noglsa, feel free to reopen if you disagree. Joshua: please file a new bug about a non-security regression bug.
