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

From: Josep L. Guallar-Esteve (guallar@easternrad.com)
Date: 03/06/03

  • Next message: Chris Santerre: "Port 113 security" 
    From: "Josep L. Guallar-Esteve" <guallar@easternrad.com>
To: "'Ali-Reza Anghaie'" <ali@packetknife.com>, <focus-linux@securityfocus.com>
Date: Thu, 6 Mar 2003 09:28:19 -0500

    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
  • Next message: Chris Santerre: "Port 113 security"

    Relevant Pages

    • Reviewed the rhn code .. RE: Red Hat Network updates
      ... We did a brief security review of the Redhat update applications ... Network" of servers, which would represent a good percentage of the ...
      (Focus-Linux)
    • Re: Odd server side scripts source disclosure vulnerability
      ... > And more likely to run on Redhat than any other one... ... Ethical Hacking at the InfoSec Institute. ... with one of our expert instructors. ... learn to write exploits and attack security infrastructure. ...
      (Pen-Test)
    • [Full-disclosure] What RedHat doesnt want you to know about ExecShield (without NX)
      ... Few of you may have seen my comments on the following article in RedHat ... I think the issue deserves more widespread attention among the security ... effort of disinformation for both SELinux and ExecShield. ... where I also comment upon some ExecShield behavior under a non-NX system. ...
      (Full-Disclosure)
    • Re: Unix runs faster, maybe
      ... Been security audited by professionals including penetration tests. ... Reality is that RH releases 10-20 *security* patches per ... Notice the 2.1 varient of RedHat is based off the five year old RedHat ... GNU Zebra is a free software that manages TCP/IP ...
      (comp.os.vms)
    • Re: Woody or Sarge
      ... New features aren't important at all. ... And with the least amount of effort, where security updates do not break ... RedHat has been a frustrating experience. ... headless servers without user intervention. ...
      (Debian-User)