Bugzilla Bug 101771

Description:
Javier Fernandez-Sanguino Pena has reported a vulnerability in FFTW, which can
be exploited by malicious, local users to perform certain actions on a
vulnerable system with escalated privileges.

The vulnerability is caused due to the temporary file
"/tmp/fftw-wisdom-to-conf$$" being created insecurely by
"/tools/fftw-wisdom-to-conf.in". This can be exploited via symlink attacks to
create or overwrite arbitrary files with the privileges of the user running the
affected application.

The vulnerability has been reported in version 3.0.1. Other versions may also be
affected.

Last release date was July 6, 2003

We'll need to patch it ourselves I guess (or drop it). Pulling in the
maintainers for advice.

Working on a patch...

Just committed 3.0.1-r2 with a patch for this file - since it's just a shell
script, it should work for other platforms aswell, but I didn't dare to keyword
them yet.

Arches, please test and mark stable, should be pretty straightforward.

Sparc stable. 'make check' is fine.

ppc stable.

compiles fine and tests fine here. 
 
-- emerge info -- 
 
Portage 2.0.51.22-r2 (default-linux/amd64/2005.1, gcc-3.4.3, glibc-2.3.5-r0, 
2.6.12-ck5 x86_64) 
================================================================= 
System uname: 2.6.12-ck5 x86_64 AMD Athlon(tm) 64 Processor 3000+ 
Gentoo Base System version 1.6.13 
ccache version 2.3 [disabled] 
dev-lang/python:     2.3.5 
sys-apps/sandbox:    1.2.11 
sys-devel/autoconf:  2.13, 2.59-r6 
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 
sys-devel/binutils:  2.15.92.0.2-r10 
sys-devel/libtool:   1.5.18-r1 
virtual/os-headers:  2.6.11-r2 
ACCEPT_KEYWORDS="amd64" 
AUTOCLEAN="yes" 
CBUILD="x86_64-pc-linux-gnu" 
CFLAGS="-march=athlon64 -O2 -fomit-frame-pointer -pipe" 
CHOST="x86_64-pc-linux-gnu" 
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" 
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" 
CXXFLAGS="-march=athlon64 -O2 -fomit-frame-pointer -pipe" 
DISTDIR="/usr/portage/distfiles" 
FEATURES="autoconfig distlocks sandbox sfperms strict" 
GENTOO_MIRRORS="ftp://ftp.rnl.ist.utl.pt/pub/gentoo/ 
ftp://ftp.gentoo-pt.org/pub/gentoo/ 
http://www.ibiblio.org/pub/Linux/distributions/gentoo 
http://distfiles.gentoo.org" 
PKGDIR="/usr/portage/packages" 
PORTAGE_TMPDIR="/var/tmp" 
PORTDIR="/usr/portage" 
PORTDIR_OVERLAY="/usr/local/portage" 
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" 
USE="amd64 X aac aalib alsa amuled avi bash-completion bitmap-fonts bzip2 c++ 
cairo ccache clamav cpudetection crypt custom-cflags directfb dlloader dts dvd 
ecc fbcon ffmpeg flac geoip gif gpm gstreamer gtk2 ipv6 ipv6arpa jpeg jpeg2k 
kde latex lcms libcaca libclamav lzo mad matroska mime mozsvg mp3 mpeg mplayer 
musepack nas ncurses nls nptl nptlonly nvidia oav offensive ogg oggvorbis 
opengl pam perl physfs pic png python qt quicktime readline real rogue rtc sdl 
smime speex sql sqlite sqlite3 ssl sysfs tcpd tga theora tidy tiff truetype 
truetype-fonts unicode usb userlocales utf8 v4l v4l2 vorbis wxgtk1 xanim 
xatrix xml xml2 xscreensaver xv xvid xvmc zlib userland_GNU kernel_linux 
elibc_glibc" 
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS 

The previous comment was from our AT.
Marked Stable on AMD64.
Thanks

Stable on hppa

stable on ppc64

Alpha happy

Cheers,
Ferdy

Ready for GLSA vote

This is pulled in by KDE not sure wether it uses the vulnerable script. I tend 
to vote YES. 

I vote for "no".

From the manpage:
       The reason to do this is that, if you only need transforms of a limited
       set of sizes and types, and if you are statically linking your program,
       then using a configuration file generated from wisdom for  those  types
       can  substantially  reduce  the  size  of your executable.

So this bug only affects the build process of programs that statically link with
fftw and that use this special feature. If there are such programs in portage it
should be sufficient to make them depend on the fixed fftw version.

Perhaps we should better check programs depending on fftw whether they link
statically and use this feature. Not very likely, though.

Thanks for the detailed explanation, I vote NO.

Patrick thx for the explanation. Reverting to full NO and closing.