Bugzilla Bug 155613

*****
- Don't use default permissions for backup file (CVE CAN-2005-1920 also applies
to kile)
*****

Flameeyes is going to check if a backport of the fix is feasible.

http://websvn.kde.org/branches/kile/1.9/kile/kile/kiledocmanager.cpp?rev=586145&view=diff&r1=586145&r2=586144&p1=branches/kile/1.9/kile/kile/kiledocmanager.cpp&p2=/branches/kile/1.9/kile/kile/kiledocmanager.cpp

1.9.2-r1 in tree, backporting the fix.

Thx Tavis/Diego.

Arches please test and mark stable. Target keywords are:

kile-1.9.2-r1.ebuild:KEYWORDS="amd64 hppa ppc ppc64 sparc x86"

Most secure and best editing experience for people who aren't smart enough for
Emacs on x86.

Emerges and works fine on amd64.

Portage 2.1.1-r2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.4-r4,
2.6.18-suspend2-Dudebox-Edition x86_64)
=================================================================
System uname: 2.6.18-suspend2-Dudebox-Edition x86_64 AMD Athlon(tm) 64
Processor 3200+
Gentoo Base System version 1.12.6
Last Sync: Mon, 20 Nov 2006 05:00:02 +0000
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[enabled]
ccache version 2.3 [enabled]
app-admin/eselect-compiler: [Not Present]
dev-java/java-config: [Not Present]
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.3
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r4
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -msse3 -Os -pipe"
CHOST="x86_64-pc-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 /var/qmail/alias
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-march=k8 -msse3 -Os -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache collision-protect distcc distlocks
metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict test"
GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/
ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/"
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j4"
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'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage_overlay"
SYNC="rsync://server/gentoo-portage"
USE="amd64 X alsa apache2 berkdb bitmap-fonts cairo cdr cli cracklib crypt cups
dbus dlloader dri dvd dvdr eds elibc_glibc emboss encode esd fam firefox
fortran gcj gdbm gif gpm gstreamer gtk gtk2 hal iconv imap
input_devices_keyboard input_devices_mouse isdnlog jpeg kde kdeenablefinal
kdehiddenvisibility kernel_linux libg++ mad mikmod mp3 mpeg mysql ncurses nls
nptl nptlonly objc objc++ ogg oss pam pcre perl png ppds pppd python qt3
quicktime readline reflection sdl session spell spl sqlite ssl tcpd test
truetype truetype-fonts type1-fonts udev unicode userland_GNU
video_cards_radeon vorbis xml xorg xv zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS,
PORTAGE_RSYNC_EXTRA_OPTS

Stable for HPPA.

sparc stable.

ppc64 stable

amd64 done.

ppc stable, this one is ready for GLSA voting.

Hm ... anybody got more flesh on this?

Sure, the apps are "network transparent" in the sense of using kio_slaves; but
those usually can't set permissions directy (like fish://, which has to use
whatever it gets on the remote side). I'm probably not recognizing the true
impact here, though. This is basically in information leakage problem, right?
In that case it only applies to configurations where the backups are stored in
some non-private area. Meaning, if I edit my
/var/lib/samba/private/supercredentials with k*, I'm fucked since my users will
know my credentials.

Bleh.

When in doubt, shove it out :P

glsa++ (catch-all rule)

Wolf for example (the output here is just made up, I dont have kde here :)

$ ls -l .fetchmailrc 
-rw------- 1 taviso users 716 2006-11-23 20:09 .fetchmailrc
$ kile .fetchmailrc &
[1] 1234
$ ls -l .fetchmailrc~
-rw-r--r-- 1 taviso users 716 2006-11-23 20:09 .fetchmailrc~

# ie, my fetchmail login credentials are now exposed.

I would vote yes.

Let's have a GLSA then.

Security, please review the draft.

GLSA 200611-21