Updated fix for CVE-2010-1000

Fixed in 4:4.6.2-0ubuntu3 in natty

Also fixed in the 4.5.5 packages currently in maverick-proposed unapproved queue. Still needs update to 4.5.1 in maverick-security.

see the debdiff for maverick in attachment

the tag "maverick-security" was missing, I also added the CVE.

The changelog now follows the format found at this page https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging

It's a debdiff for lucid

Romain, thanks for the patches. I am reviewing them now.

Felix, you stated 'The previous patch still allows up traversal at the beginning, e.g. "../foo/bar".' In bug #578856 (the original bug for CVE-2010-1000) I created a metalink file that used '<file name="../../../tmp/secunia.png">', which as you can see specifically tested if '../' was at the beginning of the string. In fact, I just tested on maverick with the metalink file I provided and when I try to open it, I see kget outputs:
kget(3314): Name attribute of Metalink::File contains directory traversal directives: "../../../tmp/secunia.png"

AFAICS, '../' at the beginning is covered. This is the code in question that was changed:
if (name.contains(QRegExp("$(\\.\\.?)?/")) || name.contains("/../") || name.endsWith("/.."))

Maybe I am blind, but I don't see what the problem is (I also tried metalink files with different combinations of '../' in the path). All I can see is that upstream check if the target file is a directory, and no longer allows '.' in the name. Can you give a string that demonstrates a file traversal/overwrite with the unpatched code?

The test doesn't catch strings that only have one ".." at the beginning.
So "../foo" passes the test while "../../foo" is caught by it.

Aha! I did not test that one. I can confirm this behavior. Thanks for the information.

What about the startsWith('/') part? This suggests previous patch may have failed to block absolute paths. Jamie, you seem to have some reproducer available, can you check that?

@Tomas,

The previous patch did block absolute paths, but it would silently fail rather than error out. Please see https://launchpadlibrarian.net/48354864/CVE-2010-1000.metalink (an attachment from bug #578856) that you can use/modify to test things. I put it in ~/Desktop then would double click on it, which would open kget.

@Romain,

I am uploading your debdiffs with the following changes:
* I am using CVE-2011-XXXX for the CVE as this will get a new CVE number assigned
* I added proper DEP-3 comments to the maverick debdiff. While what you had wasn't technically wrong, it wasn't as clean as what I've uploaded
* I added DEP-3 comments to the lucid debdiff and used the version 4:4.4.5-0ubuntu1.1 as per https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

And of course after I upload, I notice the new CVE assignment....

This is CVE-2011-1586.

This bug was fixed in the package kdenetwork - 4:4.5.1-0ubuntu2.2

---------------
kdenetwork (4:4.5.1-0ubuntu2.2) maverick-security; urgency=low

  * SECURITY UPDATE: file name directory traversal attack (LP: #757526)
    - Add debian/patches/kubuntu_06_kget_metalinker.diff: check if the
      filename is well formed, without traversal opportunities
    - CVE-2011-XXXX (incomplete fix for CVE-2010-1000)
 -- Romain Perier <email address hidden> Wed, 13 Apr 2011 19:36:45 +0200

This bug was fixed in the package kdenetwork - 4:4.4.5-0ubuntu1.1

---------------
kdenetwork (4:4.4.5-0ubuntu1.1) lucid-security; urgency=low

  * SECURITY UPDATE: file name directory traversal attack (LP: #757526)
    - Add debian/patches/kubuntu_06_kget_metalinker.diff: check if the
      filename is well formed, without traversal opportunities
    - CVE-2011-XXXX (an incomplete fix for CVE-2010-1000)
 -- Romain Perier <email address hidden> Wed, 13 Apr 2011 20:03:50 +0200

This bug was fixed in the package kdenetwork - 4:4.3.2-0ubuntu4.5

---------------
kdenetwork (4:4.3.2-0ubuntu4.5) karmic-security; urgency=low

  * SECURITY UPDATE: fix directory traversal in kget
    - debian/patches/kubuntu_06_CVE-2010-1000b.diff: more input validation due
      to incomplete fix for CVE-2010-1000
    - CVE-2011-XXXX
    - LP: #757526
 -- Jamie Strandboge <email address hidden> Fri, 15 Apr 2011 09:13:14 -0500