Hi Eric,
On Tuesday 04 March 2003 10:28 pm, Eric Greenberg wrote:
> 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.
By "is not at all pretty", what do you mean?
- Is it written in a way that is crash-prone?
- Is the code too obscured to carry on security audits?
- Is the application coded in a way that makes it "buffer-overflow-friendly"?
- Is the code not doing the job?
> From an architectural standpoint, we have at least one major concern as
> it relates to automatic (autonomous updates).
Although, in my knowledge of it, you can disable the automation, as it is a
simple daemon ("service"). By default is turned on, which is an excellent
approach to pro-active security. If the sysadmin knows her/his job, will know
about regular system updates, so the daemon can be disabled. If the sysadmin
doesn't know his/her job, it's a good thing that an automated update system
is put in place.
> 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.
Very true.
> 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.
Exactly. Although see my previous parragraph, about sysadmin knowledge.
> 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.
Aside from OpenSSL and Python, what other components are used that you believe
ned to be more reviewed?
> 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.
Although everything is possible, this is a very extreme scenario. I assume
that RedHat has measures in place so this doesn't happen. And with a man in
the middle, you are also subject to security breaches. I don't believe that a
human can always be a better security "firewall" than an electronic
counterpart. And, AFAIK, RedHat has been very diligent (and open) either
supplying patches or providing workarounds for known vulnerabilities. TRight
know, I trust RedHat.
> Regards,
> Eric
Salut,
Josep
--
Josep L. Guallar-Esteve Eastern Radiologists, Inc.
Systems and Network Administration http://www.easternrad.com
