Security: Vulnerabilites in Certain Protocols, LAN Browsing

The KDE Project today issued two security advisories which affect KDE
versions 2.1 through KDE 3.0.4 (and also through KDE 3.1 RC3). The
first
advisory
concerns the rlogin:// service and, for affected
KDE 2.x systems, the telnet:// service. The
second
advisory
concerns the LISa and resLISa
network browsing applications. Binary packages for
KDE 3.0.5 should be available by early next week (check the KDE 3.0.5 Info Page); in the interim it is
recommended to disable the affected services or upgrade from the source
code or patches.

The KDE Project today issued two security advisories which affect KDE
versions 2.1 through KDE 3.0.4 (and also through KDE 3.1 RC3). The
first
advisory
concerns the rlogin:// service and, for affected
KDE 2.x systems, the telnet:// service. These services
are implemented via .protocol files. On affected systems, the implementation
allows a carefully crafted URL in an HTML page, HTML email or other
KIO-enabled application to execute arbitrary commands on the system using
the victim's account on the vulnerable machine. The
second
advisory
concerns the LISa and resLISa
network browsing applications. The resLISa daemon contains a buffer
overflow vulnerability which potentially enables any local user to obtain
access to a raw socket if reslisa is installed SUID root. The lisa
daemon contains a buffer overflow vulnerability which potentially enables
any local user, as well a remote attacker on the LAN, to obtain root
privileges. In addition, a remote attacker potentially may be able to gain
access to a victim's account on the affected machine by using a
lan:// URL in an HTML page, HTML email or via another KDE
application. Links to the source code for KDE 3.0.5, which fixes these
problems, as well as patches to KDE 3.0.4 and instructions for disabling
the affected services are provided in the advisories. Binary packages for
KDE 3.0.5 should be available by early next week (check the KDE 3.0.5 Info Page); in the interim it is
recommended to disable the affected services or upgrade from the source
code or patches.

Dot Categories: 

Comments

by aleXXX (not verified)

may I add:

an updated version of lisa as a single package, which can be compiled independent from Qt and KDE is available at lisa-home.
It's version 0.2.2.

Bye
Alex

by Philippe Fremy (not verified)

KDE is getting security advisories these days. It seems that security people are looking at the source. This is an indication of KDE's increasing popularity.

Of course, having a security advisory is never good news, but it is still better to have one than to leave the hole.

by AC (not verified)

But as you can see, from the number of replies, nobody cares...

by a.c. (not verified)

But as you can see, from the number of replies, nobody cares...

Hummm.... A troll who spends time monitoring the KDE site. That in itself indicates that quite a few people care, one way or another. Keep up the good work KDE.

by AC (not verified)

I think people care. There is not much to say about this topic, though. Security bugs happen, it's just a fact of life. So you get the fix and move on. :-)

by zelegans (not verified)

What is there to say. They advise and I follow. Why shoul I make comments?

by Richard (not verified)

What's to say? An advisory comes out, and we pay attention. No comments needed...

I'm using Debian sid and I compiled kde 3.0.4 with gcc 3.2 with no problems but when I try to compile kdelibs 3.0.5 I get this errors:

make[5]: Leaving directory `/usr/src/kdelibs-3.0.5/obj-i386-linux/kdeprint/cups/cupsdconf2'
make[5]: Entering directory `/usr/src/kdelibs-3.0.5/obj-i386-linux/kdeprint/cups'
/bin/sh ../../libtool --mode=link gcc -DNDEBUG -O2 -o make_driver_db_cups make_driver_db_cups.o -lz ../libdriverparse.a ../../kdecore/libkdefakes.la
gcc -DNDEBUG -O2 -o .libs/make_driver_db_cups make_driver_db_cups.o -lz ../libdriverparse.a ../../kdecore/.libs/libkdefakes.so
../../kdecore/.libs/libkdefakes.so: undefined reference to `QMetaObjectCleanUp::setMetaObject(QMetaObject*&)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QMetaObjectCleanUp::~QMetaObjectCleanUp [in-charge]()'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::qt_property(int, int, QVariant*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::customEvent(QCustomEvent*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::qt_invoke(int, QUObject*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::~QObject [not-in-charge]()'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::activate_signal(int)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::qt_emit(int, QUObject*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::eventFilter(QObject*, QEvent*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::staticMetaObject()'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QMetaObjectCleanUp::QMetaObjectCleanUp[in-charge]()'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::qt_cast(char const*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QIODevice::at(unsigned long)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `operator delete(void*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QIODevice::~QIODevice [not-in-charge]()'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::childEvent(QChildEvent*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QIODevice::atEnd() const'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::disconnectNotify(char const*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QIODevice::at() const'
../../kdecore/.libs/libkdefakes.so: undefined reference to `__cxa_pure_virtual'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::setProperty(char const*, QVariant const&)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::removeChild(QObject*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QIODevice::readLine(char*, unsigned long)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::event(QEvent*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::property(char const*) const'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QMetaObject::new_metaobject(char const*, QMetaObject*, QMetaData const*, int, QMetaData const*, int, QMetaProperty const*, int, QMetaEnum const*, int, QClassInfo const*, int)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::timerEvent(QTimerEvent*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::insertChild(QObject*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `KAsyncIO::virtual_hook(int, void*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::setName(char const*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `typeinfo for QIODevice'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QIODevice::readAll()'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::connectNotify(char const*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `QObject::checkConnectArgs(char const*, QObject const*, char const*)'
../../kdecore/.libs/libkdefakes.so: undefined reference to `typeinfo for QObject'
collect2: ld returned 1 exit status
make[5]: *** [make_driver_db_cups] Error 1
make[5]: Leaving directory `/usr/src/kdelibs-3.0.5/obj-i386-linux/kdeprint/cups'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/usr/src/kdelibs-3.0.5/obj-i386-linux/kdeprint/cups'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/kdelibs-3.0.5/obj-i386-linux/kdeprint'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/kdelibs-3.0.5/obj-i386-linux'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/kdelibs-3.0.5/obj-i386-linux'
make: *** [build-stamp] Error 2

Also my compiler is:

/usr/src/kdelibs-3.0.5# gcc -v
Leyendo especificaciones de /usr/lib/gcc-lib/i386-linux/3.2.1/specs
Configurado con: /home/packages/gcc/3.2/gcc-3.2-3.2.1ds4/src/configure -v --enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-java-gc=boehm --enable-objc-gc i386-linux
Modelo de hilos: posix
gcc versión 3.2.1 20021103 (Debian prerelease)

Thanks for your atention.

These references are all provided by the QT library, which actually is called
something like 'libqt-mt.so.3.x'. So i am missing the '-lqt-mt' flag in your
linkage (line starting with 'gcc -DNDEBUG'). Probably the configure script
didn't find QT, but then it should fail with an error.
I remember when i used to play ;c) with debian, using the qt deb's results in
a strange location for the libs and includes (libs: /usr/lib/qt;
inc: /usr/include/qt) but all apps need to know where the QTDIR is, that holds
something like $QTDIR/lib and $QTDIR/include. I solved it by creating a dir like
'/usr/local/qt' as my actual QTDIR and within it i placed symbolic links, e.g
'ln -s /usr/lib/qt ./lib'. Same for includes.
If this is all garbage forget about me posting it here, and, oh well, check that you have QT installed (at all/properly)... :cP

by Andrey V. Panov (not verified)

I have got a similar problem with lpr driver on Slackware-8.1. The file kdelibs-3.0.5/kdecore/libkdefakes.la created is wrong, its entry dependency_libs
must be dependency_libs='-lqt-mt -lkdecore' .

Thank you, now all compiled fine.

Josep, how did it compile fine? I am trying to do a "compile package" for sourcemage so kde 3.0.5 will compile automatically, and this has kept me stumped. I need a configure option or a bash/sed/etc command I can run after I expand the kdelibs tarball, or between configure and make...
Thanks a lot!

Expliciting, I need to know how to change the generation of kdelibs-3.0.5/kdecore/libkdefakes.la, so I can automatically make all compile when getting to the make step.
I hope I made sense this time...

by Federico Cozzi (not verified)

In the recent versions of KDE, some interesting network programs appeared in KDE, eg the ability to share user directories via a panel applet, the network discovery facilities provided by LISA, etc...
While these programs have noble goals (simplify the use of the network for users), it looks like their developers are not completely proficient with the security problems related with network servers programming.
Network server programming is a hard beast, look at the number of bugs of well-known servers (e.g. sendmail, bind, etc...) - and these servers are developed by programmers with lots of expertise in that area.
I think KDE developers are a little naive because they "reimplement" network server facilities within KDE, without having the necessary expertise. This immediately causes security bugs, as the recent KDE history shows...
So, I humbly suggest them NOT to reimplement network server from scratch; please use more tested and reliable software (e.g. apache, samba) and implement a KDE addon/GUI interface/whatever to simplify their use.
This is more or less the path followed by MacOsX: if you want to share a directory, the system modifies the configuration file of the Apache webserver installed on the computer. Apple did not reimplement a file server just for this...

by Julien Olivier (not verified)

Hi

I totally agree with you. But I'd like to add that if you use Mandrake, you'll see that it becomes quite ridiculous because you have two ways to share files: one way provided by Mandrake and based on NFS and one based on KDE file sharing applet. So you have a good way to do that (mandrake's way) and KDE's way to do that. For the user, it's another stupid thing about Linux (people often don't know that Linux!=Mandrake!=KDE). I know this is Mandrake's fault because they should remove KDE file sharing applet. BUT, why don't KDE developers include Mandrake's NFS utility into KDE CVS ? It's GPL so it can be included. But no... we have two tools for the same thing...

by matthes (not verified)

The KDE developers did not reimplement all services.

For LiSA, they just redistribute it and added a configuration module. The file sharing works via modifying the smb.conf file. For this you have to have the "fileshare..." tool installed, which is developped by Mandrake. And it uses samba to provide the server functions.

Ciao, matthes

by Federico Cozzi (not verified)

> For LiSA, they just redistribute it and added a configuration module.

The distinction between "just redistributing" and "including" is blurry...
Lisa is part of KDE packages since v 2.something, is developed by a KDE developer and is used only by KDE (to my knowledge); it even has a control module. I would say it is part of KDE...

> The file sharing works via modifying the smb.conf file

No it does not work this way, at least on KDE3.0. There is a panel applet (kpf, part of kdenetwork) which implements a minimal HTTP server.

You are speaking about Mandrake's KDE (modified to use samba), or KDE 3.1 which includes Mandrake's code to modify the configuration files of Samba and NFS daemon. This looks to me the best way to provide file sharing services, I'm happy that KDE adopted this way.

>There is a panel applet (kpf, part of kdenetwork) which implements a minimal HTTP server.

Yes, and what is this panelaplet suposed to do? Kpf is quik and easy way to temporary share some files to the net. The key here is temporary, it's meant to be set up and taken down with ease and not to run as a permanent file share service. Only look how it's implemented, a minimal HTTP server running as a panel applet. Not exactly a high performance or scalabel way to do file sharing, but quik, easy and uncomplicated as it was designed to be. To be naive is to think it's developed to replace file sharing services like NFS or samba.

by aleXXX (not verified)

Well, lisa is part of KDE, but can be used completely independent.
I didn't find time yet to write a Gnome vfs module.
And give us the chance to learn about secure programming.
I'd say lisa is now quite secure. It's only a small project, I think it must be less than 1000 LOC. It is possible to get it secure.
Actually I'm happy the problems were found :-)

Bye
Alex, the author

> it looks like their developers are not completely proficient with the security problems related with network servers programming.

Do you think apache has never had a security bug? If you do, you're a bit naive.

by Federico Cozzi (not verified)

> Do you think apache has never had a security bug? If you do, you're a bit naive.

No, the naivety is thinking that "apache has bugs and lisa has bugs" implies "apache and lisa are at the same level of security" (just to name two random projects).
Apache is an old, well tested software. The most trivial bugs have already been fixed. You can't say the same of lisa (for example).
For example, apache runs as user "nobody". You can't (easily) get root access via apache. Lisa does not have this level of security.

by Roberto Alsina (not verified)

But kpf does.

by Anonymous..... (not verified)

Too much eye candy and bad security ....
i'm switched to GNOME 2 ...

by asf (not verified)

cool. using any open sourced desktop is fine.. just dont switch to osx/windowsxp :)