JAN
20
2006

Security: KJS and KPDF Security Advisories

The KDE Project released a security advisory today for a heap overflow vulnerability in KJS. Earlier this month, a number of integer overflows affecting KPDF, and consequentially KOffice were found and fixed. Patches have been made available and your distributor should have updated binary packages. The KDE security advisory page has an overview of all KDE advisories. Links to source patches are contained in the advisories.

Comments

what about a k_patch_gethotnewstuff, gets all the files it needs , compiles, and replaces only the files it has to.

Because it does not create new files, it will not conflict with the package management of the various distributions.

just an idea, i have not the time to implement it.


By chris at Fri, 2006/01/20 - 6:00am

"k_patch_gethotnewstuff" would need to be run as root, and would change the checksums of the apps installed by the distro tools, which might cause them to freak out. Using the distro's own updating tool would be far simpler (especially since a lot of distros patch KDE with their own custom patches).


By Corbin at Fri, 2006/01/20 - 6:00am

Doesn't prelinking already do that?


By greg at Fri, 2006/01/20 - 6:00am

The CRCs are only for *Complete* Packages , and only used @ install. If you would change a file while its installed , the package managers will never know.

The advantage is clear : Fast Security Fixes.


By chris at Fri, 2006/01/20 - 6:00am

No. RPM based systems has a db of hashes of all the files belonging to installed packages.
So 'rpm -qf /usr/bin/dvd+rw-mediainfo' gives the answer "dvd+rw-tools-6.0-2".
You can't change anything on the file without altering its hash value, and thereby rendering it "unknown" to the RPM db.

rpm -qfi and rpm -V -a are very handy. The latter checks for any changes to filesizes permissions etc etc, to all installed packages.

I would rather have large updates, than losing my ability to do basic security checks of installed software on my box.


By Peter H.S. at Fri, 2006/01/20 - 6:00am

ah ok didnt know that, but the DB is not checked upon removal , only for security checks .

If an attacker changes a file, he will most probably change the checksum too, so i dont think you should trust thats silly check.

Patch the System in the first place, and the chance an attacker replaces a file because he broke through that hole ist gone.

As linux marketshare rises, we musst have the ability to fix problems instant, and a gentoo like system where the system compiles the needed stuff and replaces it would be nice.

If it work well, then the packagemanagers can implement something like : "register changed file in package X"


By chris at Fri, 2006/01/20 - 6:00am

Even if the attacker alters the DB (generally that isn't done), you could still check against the RPM files. Gentoo also does a similar thing (at least for the config files, not sure about everything else). Gentoo also doesn't instantly get the new versions, someone has to update the ebuilds (with either a new tar.{gz,bz}, or add the patches to the list of patches).

It also probably would be faster in most cases to wait for the distro to release new packages rather than compiling it on the local system (think ccache and distcc). KDE really shouldn't encroach on the package manager's territory (most distros would probably patch KDE so it wouldn't update then).


By Corbin at Fri, 2006/01/20 - 6:00am

I am fully aware, that one can never check the integrety of a system from it self, though one can actually perform a "tripwire" like check of the installed rpms from a read-only media with similar rpms on.

It is not trivial to change a hash value in the RPM db, and certainly not in a automatic way. Most attacks are automatic-scripts, either by script-kiddies, or spammers, and therefore "rpm -V -a" gives a reasonably defence against root-kits that overwrite systemfiles.

The present system with signed rpm packages, containing a full version of the fixed program is lightyears better than anything the competition has. The only downside is bandwith usage, which sucks for modem-users. Then again, it always sucks to be a modem user.

System integrety is more than intrusion detection, and your proposal simply break any existing pagkage system, without any gain what so ever.
You talk about some "ability to fix problems instant", and in the next sentence about patching source code and recompiling? Applying a large rpm package is so much faster, than recompiling even a medium-sized program.

I vastly prefer "new_fixed_package.rpm" instead of "old_package.rpm + hotfix+hotfix+hotfix. It is so much easier, faster and simpler to deal with.

--
Regards
Peter H.S.


By Peter H.S. at Sat, 2006/01/21 - 6:00am

Dumb idea.


By Anonymous at Sat, 2006/01/21 - 6:00am

i dont think so , you can also use this for development - it monitors #kde-commits , and if you choose update , it compiles only a few files , and your ready.


By chri at Sat, 2006/01/21 - 6:00am

kdesvn exists - for building from source but not for updating a binary distribution.


By Anonymous at Sun, 2006/01/22 - 6:00am

completly OT:

i hope you all have seen http://kde-files.org/

nice !


By chris at Sun, 2006/01/22 - 6:00am

@@ -257,6 +262,12 @@ UString decodeURI(ExecState *exec, UStri
assert(n == 4);
unsigned long uuuuu = ((octets[0] & 0x07) << 2) | ((octets[1] >> 4) & 0x03);
unsigned long vvvv = uuuuu-1;

Variables named "uuuuu" and "vvvv"?!
Really impressive to have code of this quality in kdelibs.


By EHa at Sun, 2006/01/22 - 6:00am

did you see the semantics behind those variables ? i think its ok
the number of chars mean something.


By chris at Sun, 2006/01/22 - 6:00am

That question was answered in a comment over Slashdot (http://it.slashdot.org/comments.pl?sid=174643&cid=14527629):

«Check section 15.1.3 of the ECMA standard (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf), which the source refers to. The algorithm is explained there, and the variable names are taken from the standard for readability.

Sheesh, do a little homework first.»


By blacksheep at Sun, 2006/01/22 - 6:00am

No news about the Firefox port to Qt?

Are there still issues with kde devs not getting cvs access to the Mozilla codebase?


By ac at Sun, 2006/01/22 - 6:00am

Firefox is being ported to Qt by KDE developers?


By blacksheep at Sun, 2006/01/22 - 6:00am

> Firefox is being ported to Qt by KDE developers?

Yes :-)

http://dot.kde.org/1094924433/


By ac at Sun, 2006/01/22 - 6:00am

Unfortunately that message was from September 2004....

Would be nice to see something by now.... Would make my use linux a lot more...


By boemer at Sat, 2006/02/18 - 6:00am

Everyone has access to the Mozilla CVS...


By Reply at Sun, 2006/01/22 - 6:00am

I repeat, everyone has access to the Mozilla CVS.

As for commit rights, the link you posted answers the question. Nothing stops anyone from porting the code. It's very simple, you start contributing patches and when enough of them are accepted you'll probably get a CVS account. And if you don't, you can rely on other people commiting the patches or making them available as a branch somewhere else.


By Reply at Mon, 2006/01/23 - 6:00am