Reviewed the rhn code .. RE: Red Hat Network updates

From: Eric Greenberg (
Date: 03/05/03

  • Next message: Kevin Sonney: "Re: Red Hat Network updates"
    From: "Eric Greenberg" <>
    To: "'Ali-Reza Anghaie'" <>, <>
    Date: Tue, 4 Mar 2003 22:28:45 -0500

    We did a brief security review of the Redhat update (rhn) applications
    and code. Everything previously mentioned in the previous posts is what
    we saw-- it uses https and gpg, the combination of which is quite
    powerful. However, the code itself, as I recall much of which is
    written in Python (in the 7.x system we reviewed), is not at all pretty.
    It's not cleanly implemented and in my opinion Redhat should go back and
    rewrite a great deal of it.

    From an architectural standpoint, we have at least one major concern as
    it relates to automatic (autonomous updates). But before I comment on
    that, I do want to make it clear my overall opinion is that the Redhat
    update toolset offers tremendous overall benefits. Even with all of its
    risks, it provides an extremely well-done and easy-to-use way for
    administrators to keep-up with updates, one of the biggest problems in
    security on the Internet today. At the same time, it is a tremendously
    risky single point of failure that folks managing sensitive high-impact
    servers must give serious thought to and perhaps reconfigure.

    From a reconfiguration standpoint, I advise clients to disable the rhn
    agent (rhnsd) and instead suggest applying those updates in a controlled
    fashion while logged-into the system, either downloaded manually after
    an md5sum/checksum validation or through the up2date -l followed by an
    up2date -u if you are comfortable with it.

    The problem with rhnsd is that it is a process always running, and its
    power to update every aspect of the software is quite extreme. While
    components it uses (e.g. OpenSSL) have received considerable review, not
    all of its components have received the level of peer-review I think it
    warrants. If there is a vulnerabilty in it anywhere, the "Redhat
    Network" of servers, which would represent a good percentage of the
    Internet, will tumble to the ground. There are several risk areas
    relative to compromise, one being that Redhat servers are hacked
    considerably (down to their private keys) after which malicious software
    is propagated to all Redhat network servers. Admittedly the alternative,
    patches we apply manually can be compromised, but it happens with a
    human being in the middle checking things in some way in accordance with
    some kind of known organizational policy and procedures you have
    in-place for your Linux servers.
    Mission Critical Security Planner:
    When hackers won't take no for an answer

  • Next message: Kevin Sonney: "Re: Red Hat Network updates"