[ISN] The wrong way to upgrade your RPMs

From: InfoSec News (isnat_private)
Date: Fri Sep 12 2003 - 00:12:08 PDT

  • Next message: InfoSec News: "[ISN] Electrical Grid Vulnerable to Hackers"

    |  Linux Security: Tips, Tricks, and Hackery                       |
    |  Published by Onsight, Inc.                                      |
    |                                                                  |
    |  11-September-2003                                               |
    |  http://www.hackinglinuxexposed.com/articles/20030911.html       |
    This issue sponsored by Onsight, Inc, your source for open-source
    Onsight offers on-site training on Linux software development, Linux,
    Unix, and Network Security, Basic/Advanced Perl programming, CGIs and
    Dynamic Web Content, Tcl/Tk, and XML. All courses are hands-on,
    designed by real-world consultants and fully customizable. Every
    Onsight instructor is a seasoned consultant able to provide back-end
    web programming, network security, system administration and other
    support services.
    For more information, visit http://www.onsight.com
    The wrong way to upgrade your RPMs
    By Brian Hatch
    Summary: Keeping your machine up to date requires that you update
    your software. If your distro uses RPM packages, be sure you aren't
    accidentally installing new software when you upgrade.
    Most Linux distributions use the RPM[1] format for their software
    packages. RPMs are managed by the rpm program, which typically lives
    at /usr/bin/rpm.[2]
    The problem with any system is that your software is out of date the
    second you install it, and when security problems are found, you need
    to upgrade your software. Linux is great in that you don't need to
    reboot, you can upgrade your software on the fly.[3]
    Most Linux distributions maintain a web or FTP site that provides
    updated RPMs for security or other critical bugs. Some even include
    handy helpful programs to make it easier to identify older software
    and automatically upgrade to the newest available version, for
    example Red Hat's up2date. Some of these are subscription based (hey,
    creating good tools and providing the bandwidth costs money) so often
    people prefer to simply upgrade their RPMs directly.
    It's fairly trivial to mirror the updates section of your distro's
    website. For example I used to use the following to snag all the Red
    Hat 6.2 upgrade RPMs:
      $ wget ftp://ftp.valinux.com/pub/mirrors/redhat/redhat/updates/6.2/en/os/i386
    The above command would download all the x86 updates. Run it nightly
    from cron, and you've always got a repository of updated packages.
    Now that you have them, it's time to upgrade. Say you are running
    Apache (who isn't) and there's an upgrade for it, you'd do the
    following to upgrade:
      # cd /path/to/my/mirrored/upgrade/packages
      # rpm -U apache-1.3.27.rpm
    The -U option to rpm tells it to upgrade the package, which is
    effectively just an install of the new package followed by an
    uninstall (erase) of the old. Your configuration files are all left
    alone, and in the case of security upgrades you shouldn't need to
    make any changes.[4] Life is good.
    Now wouldn't it be tempting to just run rpm -U out of cron after the
    directory is mirrored? Yes, it is tempting, and it's problematic, and
    here's why:
    Calling rpm -U will upgrade a package even if it isn't already
    installed. So if you weren't running Apache and attempt to 'upgrade'
    it, rpm -U will install it for you! Now you're running something you
    weren't expecting, and probably aren't paying attention to. The less
    software you have installed and running, especially
    network-accessible daemons, the better.
    Instead of using rpm -U, you should use rpm -F. The -F stands for
    'freshen', and is the same as 'upgrade' except that it will only
    install the upgraded package if the old version is already installed.
    This will prevent you from accidentally installing something that
    wasn't installed.
    If you do want to run upgrades out of cron (which I don't suggest in
    general), be careful about kernel upgrades. These should only be
    installed manually, lest you end up rendering your machine unable to
    boot, have a foobared /etc/lilo.conf or /etc/grub.conf, or install
    kernel includes that are incompatible with your current running
    kernel and goof up subsequent software compiles.
    [1] RPM stands for "Red Hat Package Manager", created by,
    unsurprisingly, Red Hat.
    [2] Naturally there are many front ends to rpm functionality. I'll
    admit, I'm an old foggie command line guy, and just can't keep up
    with the GUI frontend of the week.
    [3] In many cases, such as daemon programs, you need to restart your
    software, and this is likely not built into the post-upgrade
    functionality of the RPM. See the article "Upgrade Process:
    Restarting vs Rebooting" (http://www.hackinglinuxexposed.com/articles
    [4] Usually, when a package has a security problem, the bug is fixed
    in the exact same version of the software, rather than upgrading you
    to a new version of the software. Upgrading Apache-1.3.x to
    Apache-1.3.y could cause problems (perhaps some of your modules
    aren't available for the new version) so patches are 'backported' to
    the currently-available version when necessary. Because of this, you
    shouldn't need to change any of your configuration or setup in 95% of
    your upgrades.
    Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
    Linux Exposed and Building Linux VPNs. He gets a lot of work done at
    Starbucks while waiting for his wife's car to get fixed. If only he
    had a second battery for his laptop... Brian can be reached at
    This newsletter is distributed by Onsight, Inc.
    The list is managed with MailMan (http://www.list.org). You can
    subscribe, unsubscribe, or change your password by visiting
    http://lists.onsight.com/ or by sending email to
    Archives of this and previous newsletters are available at
    Copyright 2003, Brian Hatch.
    ISN is currently hosted by Attrition.org
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.

    This archive was generated by hypermail 2b30 : Fri Sep 12 2003 - 02:50:44 PDT