Security: KJS and KPDF Security Advisories

Friday, 20 January 2006  |  Jriddell

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:

Auto_Patch_Install - chris - 2006-01-20

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.

Re: Auto_Patch_Install - Corbin - 2006-01-20

"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).

Re: Auto_Patch_Install - Greg - 2006-01-20

Doesn't prelinking already do that?

Re: Auto_Patch_Install - chris - 2006-01-20

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.

Re: Auto_Patch_Install - Peter H.S. - 2006-01-20

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 <filename> 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.

Re: Auto_Patch_Install - chris - 2006-01-20

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"

Re: Auto_Patch_Install - Corbin - 2006-01-20

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).

Re: Auto_Patch_Install - Peter H.S. - 2006-01-21

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<largenumber>+hotfix<largenumber>+hotfix<largenumber>. It is so much easier, faster and simpler to deal with. -- Regards Peter H.S.

Re: Auto_Patch_Install - Anonymous - 2006-01-21

Dumb idea.

Re: Auto_Patch_Install - chri - 2006-01-21

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.

Re: Auto_Patch_Install - Anonymous - 2006-01-22

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

kde-files.org - chris - 2006-01-22

completly OT: i hope you all have seen http://kde-files.org/ nice !

Variable names - EHa - 2006-01-22

@@ -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.

Re: Variable names - chris - 2006-01-22

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

Re: Variable names - blacksheep - 2006-01-22

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.»

firefox-Qt - ac - 2006-01-22

No news about the Firefox port to Qt? Are there still issues with kde devs not getting cvs access to the Mozilla codebase?

Re: firefox-Qt - blacksheep - 2006-01-22

Firefox is being ported to Qt by KDE developers?

Re: firefox-Qt - ac - 2006-01-22

> Firefox is being ported to Qt by KDE developers? Yes :-) http://dot.kde.org/1094924433/

Re: firefox-Qt - boemer - 2006-02-18

Unfortunately that message was from September 2004.... Would be nice to see something by now.... Would make my use linux a lot more...

Re: firefox-Qt - Reply - 2006-01-22

Everyone has access to the Mozilla CVS...

Re: firefox-Qt - firefox - 2006-01-22

https://bugzilla.mozilla.org/show_bug.cgi?id=297788

Re: firefox-Qt - Reply - 2006-01-23

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.