Security: Potential Local Root Exploit (Artswrapper)

A possible local root exploit affecting all versions of artswrapper
(introduced in KDE 2 pre-releases) was posted late Sunday to some of the well-known
security websites. The exploit only affects installations which
have installed artswrapper setuid "root".
A patch
(GPG
signature
) against KDE 3.0.2 was released almost immediately (thanks
to George Staikos and Dirk Mueller), and new packages
are being built.
In the meantime, it is strongly recommended that system administrators
unset the setuid bit on artswrapper (e.g., chmod ug-s
artswrapper
), particularly on multi-user machines.
More details, as they arise, will be posted to the
KDE 3.0.2 Info Page.

Update: 07/08 19:25:49 by N: There appears to be some confusion as to whether this is a real exploit or not. The patch has currently been retracted, so stay tuned for updates. As usual, those of you who wish to err on the side of caution simply have to remove the setuid bit on artswrapper.

Dot Categories: 

Comments

by Daniel Stone (not verified)

The quote that came up as I looked at this story was:
"Security is not optional." -Waldo Bastian

by topace (not verified)

The link to the patch file is 404. Or, maybe im jumping the gun and I actually read the story before the patch got uploaded :)

topace

by Troy Unrau (not verified)

no, it's 404 for me too

by Michael Soibelman (not verified)

Ditto. File does not exist....Maybe we should WAIT????

by jmalory (not verified)

What happens if I remove the suid bit? Does it still function properly? If so, what was the point of having it suid root in the first place?

by Navindra Umanee (not verified)

I think it was there so that arts could obtain real-time priviledges if requested by the user. Otherwise, assuming arts has access to the sound device, I assume it should work fine.

by Evan "JabberWok... (not verified)

A user cannot normally raise the execution priority of a process under Linux beyond a certain point. For things like sounds, you want them to sync perfectly, and you (hopefully) know that they only have a certain system load, so it's nice to have them at a very high execution priority (pun intended).

Note that many other OSes have fine grained security systems, which allow you to give a process the rights to change its priority without being able to do anything else (like change passwords for root). There has been talk that Linux will be getting progressivly more fine grained security in the future, and some of the 2.5.x work is being done with an eye towards that.

Remember, this is only a security risk if you have people you don't trust using your system (either at the console or via telnet or ssh), and even then, it's theoretical, and may not even exist. For the majority of desktop users, this is not a concern, and most servers don't even have monitors, let alone soundcards or a desktop.

--
Evan

by Carbon (not verified)

Such fine-grained security already exists in Linux to some degree. In particular, take a look at some of the more secure chroot systems: within a chroot jail, it's important to deny the chroot system call to a root user or they can easily break out. I think it's really just a matter, at this point, of making it more fine grained. Then again, I'm not a kernel developer, so just ignore me. :-)

Of course, Linux kernel since 2.something allows using capabilities. Except that nothing uses it, because "it is not portable to other systems".

by ksh (not verified)

where can i find information about that bug ?!
havent seen anything on bugtraq