Reviewed the rhn code .. RE: Red Hat Network updates
From: Eric Greenberg (email@example.com)
From: "Eric Greenberg" <firstname.lastname@example.org> To: "'Ali-Reza Anghaie'" <email@example.com>, <firstname.lastname@example.org> 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