Find the answer to your Linux question:
Results 1 to 8 of 8
Hi All, I amusing centos 5.8 with tar-1.15.1-31.el5(tar-1.15.1-31.el5.i386) and to address the vulnerability,I thought of upgrading the version to 1.15.91 as per the vulnerability description. But when i try to ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    May 2014
    Posts
    15

    Upgrading tar to address CVE-2006-0300


    Hi All,

    I amusing centos 5.8 with tar-1.15.1-31.el5(tar-1.15.1-31.el5.i386) and to address the vulnerability,I thought of upgrading the version to 1.15.91 as per the vulnerability description.

    But when i try to upgrade,
    rpm -Uvh tar-1.15.91-1mdv2007.0.i586.rpm
    Preparing... ########################################### [100%]
    package tar-1.15.1-31.el5.i386 (which is newer than tar-1.15.91-1mdv2007.0.i586) is already installed

    Since I am not able to get the rpm in i386 architecture I have used rpm in i586 architecture.

    Please help to find the exact version that this vulnerability is resolved.

    Thanks,

  2. #2
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,425
    That bug is so ancient, that redhat only mentiones rhes4 as updated system.
    https://access.redhat.com/security/cve/CVE-2006-0300

    I am quite sure, that the patch made it into rhes5 and rhes6 as well.

    So: Nothing to do here.
    The installed version is fine.
    You must always face the curtain with a bow.

  3. #3
    Just Joined!
    Join Date
    May 2014
    Posts
    15
    Great,Thanks Genius.

    One more small query.

    How will you say that it got fixed from rhes4 from the link you provided.Is it like the platforms have the fix which are mentioned under Redhat security errata.

    whether 1.15.1-31 is newer than 1.15.1-91?

    What is the latest version of tar that's available for centos 5.8

  4. $spacer_open
    $spacer_close
  5. #4
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,425
    Two reasons:
    1) Look carefully at the versions.
    tar-1.15.1-31.el5.i386 vs tar-1.15.91-1mdv2007.0.i586

    a) The upstream versions are 1.15.1 vs 1.15.91.
    This denotes the version from here
    Tar - GNU Project - Free Software Foundation

    b) But then there are revision numbers ( -31 vs -1mdv2007.0 ) handled by the package maintainers, not upstream developers.
    So Redhat (el = enterprise linux) applied patchset 31 on top 1.15.1
    while mandriva (mdv) applied probably one on top of 1.15.91.

    2) The way software development works.
    I showed you the link in which redhat announces the fix to this CVE for redhat4.
    So redhat has this backport patch.
    Now what happens if a new major version of redhat enterprise linux is developed?
    Will they throw away everything they learned from the previous version and start from scratch?
    Unlikely.
    They will decide for every package they need on a new upstream version and then will apply their previous patches (as far as it makes sense)

    But if you want to be *really* sure:
    - Read the affected codesnippet of CVE-2006-0300
    - Read the patch
    - Get the source rpm of tar-1.15.1-31

    And then see, if that code part has been fixed in tar-1.15.1-31


    Two more notes:
    1) I assume,
    - you looked up CVE - CVE-2006-0300
    - read the first sentence "Buffer overflow in tar 1.14 through 1.15.90"
    - and then you tried to find a rpm with version 1.15.91
    - you found a mandriva rpm with upstream version 1.15.91
    - Then you tried to install that

    And here lies the problem.
    Packages of the various distributions are *not* interchangeable, even if they use the same package format.
    The package dependencies may be different, the paths of the files/directories may be different, the patchsets may be different.

    Mixing packages *will* lead to chaos, aka:
    Updates will no longer work, apps and tools might crash because libs, features and files are not there or different.

    2) If you read the references of CVE - CVE-2006-0300 then you will see the link to redhat.
    It is the same I posted earlier.
    https://rhn.redhat.com/errata/RHSA-2006-0232.html

    Or in other words
    - The CVE describes the bug in detail
    - The reference list points you to your distributions site on which you can see how this bug is handled within the distribution.
    Last edited by Irithori; 05-23-2014 at 09:54 AM.
    You must always face the curtain with a bow.

  6. #5
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,425
    One more thing:
    Not to imply anything bad.
    But from experience I know that one reason why people go "rpm hunting" for rhel is, that they cannot use the package manager yum.

    Why cant they use yum?
    Because they didnt pay for the annual subscription.

    In this case, I recommend migrating the servers to centos or scientific linux.
    Both are binary compatible redhat clones, which do not require a paid subscription, but also dont have commercial support (by default).
    You must always face the curtain with a bow.

  7. #6
    Just Joined!
    Join Date
    May 2014
    Posts
    15
    Hi Irithori,

    I downloaded the src file for 1.15.1-31 and found the fix for the vulnerability also from the net.

    But when i checked the source I am not able to find the fix for CVE-2006-0300 in 1.15.1-31

    I am placing the diff for CVE-2006-0300 here.

    * SECURITY UPDATE: Arbitrary code execution with crafted tar files.
    * src/xheader.c:
    - Add a new function decode_num() which wraps xstrtoumax() and adds
    boundary and sanity checking.
    - Use decode_num() instead of xstrtoumax() in the code to avoid buffer
    overflows on excessively large field values like GNU.sparse.numblocks.
    - Patch taken from upstream CVS.
    * CVE-2006-0300

    --- src/xheader.c.orig 2004-09-06 06:31:14.000000000 -0500
    +++ src/xheader.c 2006-02-08 16:59:46.000000000 -0500
    @@ -783,6 +783,32 @@ code_num (uintmax_t value, char const *k
    xheader_print (xhdr, keyword, sbuf);
    }

    +static bool
    +decode_num (uintmax_t *num, char const *arg, uintmax_t maxval,
    + char const *keyword)
    +{
    + uintmax_t u;
    + char *arg_lim;
    +
    + if (! (ISDIGIT (*arg)
    + && (errno = 0, u = strtoumax (arg, &arg_lim, 10), !*arg_lim)))
    + {
    + ERROR ((0, 0, _("Malformed extended header: invalid %s=%s"),
    + keyword, arg));
    + return false;
    + }
    +
    + if (! (u <= maxval && errno != ERANGE))
    + {
    + ERROR ((0, 0, _("Extended header %s=%s is out of range"),
    + keyword, arg));
    + return false;
    + }
    +
    + *num = u;
    + return true;
    +}
    +
    static void
    dummy_coder (struct tar_stat_info const *st __attribute__ ((unused)),
    char const *keyword __attribute__ ((unused)),
    @@ -821,7 +847,7 @@ static void
    gid_decoder (struct tar_stat_info *st, char const *arg)
    {
    uintmax_t u;
    - if (xstrtoumax (arg, NULL, 10, &u, "") == LONGINT_OK)
    + if (decode_num (&u, arg, TYPE_MAXIMUM (gid_t), "gid"))
    st->stat.st_gid = u;
    }

    @@ -903,7 +929,7 @@ static void
    size_decoder (struct tar_stat_info *st, char const *arg)
    {
    uintmax_t u;
    - if (xstrtoumax (arg, NULL, 10, &u, "") == LONGINT_OK)
    + if (decode_num (&u, arg, TYPE_MAXIMUM (off_t), "size"))
    st->archive_file_size = st->stat.st_size = u;
    }

    @@ -918,7 +944,7 @@ static void
    uid_decoder (struct tar_stat_info *st, char const *arg)
    {
    uintmax_t u;
    - if (xstrtoumax (arg, NULL, 10, &u, "") == LONGINT_OK)
    + if (decode_num (&u, arg, TYPE_MAXIMUM (uid_t), "uid"))
    st->stat.st_uid = u;
    }

    @@ -946,7 +972,7 @@ static void
    sparse_size_decoder (struct tar_stat_info *st, char const *arg)
    {
    uintmax_t u;
    - if (xstrtoumax (arg, NULL, 10, &u, "") == LONGINT_OK)
    + if (decode_num (&u, arg, TYPE_MAXIMUM (off_t), "GNU.sparse.size"))
    st->stat.st_size = u;
    }

    @@ -962,10 +988,10 @@ static void
    sparse_numblocks_decoder (struct tar_stat_info *st, char const *arg)
    {
    uintmax_t u;
    - if (xstrtoumax (arg, NULL, 10, &u, "") == LONGINT_OK)
    + if (decode_num (&u, arg, SIZE_MAX, "GNU.sparse.numblocks"))
    {
    st->sparse_map_size = u;
    - st->sparse_map = calloc(st->sparse_map_size, sizeof(st->sparse_map[0]));
    + st->sparse_map = xcalloc (u, sizeof st->sparse_map[0]);
    st->sparse_map_avail = 0;
    }
    }
    @@ -982,8 +1008,14 @@ static void
    sparse_offset_decoder (struct tar_stat_info *st, char const *arg)
    {
    uintmax_t u;
    - if (xstrtoumax (arg, NULL, 10, &u, "") == LONGINT_OK)
    + if (decode_num (&u, arg, TYPE_MAXIMUM (off_t), "GNU.sparse.offset"))
    + {
    + if (st->sparse_map_avail < st->sparse_map_size)
    st->sparse_map[st->sparse_map_avail].offset = u;
    + else
    + ERROR ((0, 0, _("Malformed extended header: excess %s=%s"),
    + "GNU.sparse.offset", arg));
    + }
    }

    static void
    @@ -998,15 +1030,13 @@ static void
    sparse_numbytes_decoder (struct tar_stat_info *st, char const *arg)
    {
    uintmax_t u;
    - if (xstrtoumax (arg, NULL, 10, &u, "") == LONGINT_OK)
    + if (decode_num (&u, arg, SIZE_MAX, "GNU.sparse.numbytes"))
    {
    if (st->sparse_map_avail == st->sparse_map_size)
    - {
    - st->sparse_map_size *= 2;
    - st->sparse_map = xrealloc (st->sparse_map,
    - st->sparse_map_size
    - * sizeof st->sparse_map[0]);
    - }
    + st->sparse_map = x2nrealloc (st->sparse_map,
    + &st->sparse_map_size,
    + sizeof st->sparse_map[0]);
    +
    st->sparse_map[st->sparse_map_avail++].numbytes = u;
    }
    }


    Can you please look into this.

  8. #7
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,425
    And why would I dig through the code?
    You are the one interested, so.. have fun.

    Sent from my GT-I9505 using Tapatalk
    You must always face the curtain with a bow.

  9. #8
    Just Joined!
    Join Date
    May 2014
    Posts
    15
    I have confirmed my tar version has the fix for CVE-2006-0300 by using the changelog.

    rpm -q --changelog tar | grep CVE
    - CVE-2007-4476 - fix stack crashing in safer_name_suffix
    - CVE-2010-0624 - fix heap-based buffer overflow by expanding
    - CVE-2007-4131 tar directory traversal vulnerability (#251921)
    - fix CVE-2006-6097 GNU tar directory traversal
    - fix heap overlfow bug CVE-2006-0300 (#181773)

    Thanks for you help on this.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •