April 25, 2007
This article was contributed by Jake Edge.
A recently released
report
on the security track record of Red Hat Enterprise Linux 4 (RHEL4) sets out
to quantify the risks that an administrator would have faced when using
the distribution. It takes a comprehensive look at all of the vulnerabilities
that were classified as 'critical' in the two years since RHEL4 was released.
A measure of pride is evident in the recognition that there were only three
critical vulnerabilities in the default server install, a rather
nice accomplishment; the study itself is an even better result and it
should set the bar for other similar studies in the future.
In stark contrast to almost daily studies that purport to 'prove' that
Redmond's latest offering is vastly superior to Linux in the security arena,
the RHEL study simply looks at the reported vulnerabilities
in that distribution and leaves any comparisons for others. The study mainly
focuses on the critical vulnerabilities, but it does look at the
'Vulnerability Workload Index' for a server install with all available packages.
This index is meant to give a rough measure of the amount of work an
administrator would need to do to keep a system free from all vulnerabilities.
The most interesting conclusion that can be drawn from the graph is that
the overall workload is pretty flat, there are certainly peaks, but it
is neither increasing nor decreasing over time. Because the software released
with RHEL4 is, of course, getting older and the upstream projects are likely
to be releasing newer versions, a case could be made either way regarding
increasing stability vs. more security issues found over time and it
would appear that the two roughly balance each other.
Flaws that get the 'critical' designation are those that can lead to a system
compromise in an automatic way without any user action. These are the kinds
of bugs that could be exploited by worms to invade and propagate. The
critical designation has been stretched to cover web browser bugs that
are exploited when a user visits a site with malicious code. The vast
majority of critical bugs fall into the latter category and that difference
leads to 60 flaws in a system with all packages installed, 50 of which
can be traced to Mozilla products or the HelixPlayer plugin.
The study goes into the 60 critical flaws in some depth, categorizing them by
type and reporting on the so-called 'days of risk' (number of days after
a vulnerability report before a fix is available). All critical flaws were
fixed within two calendar days and 60% were fixed on the same day. The
riskiest packages are also listed using a weighted score based on
the number and severity of bugs in that package with various Mozilla projects
coming out on top. Interestingly, the kernel dropped from #1 last year to #4
in the current report.
The risk to a system is not only a function of the vulnerabilities in the
packages it has installed; exploits 'in the wild' also factor into it.
The report looks in detail at exploits for
37 vulnerabilities, many of which are, unsurprisingly, either browser
or 'user complicit' exploits. Triggering a user complicit exploit requires
convincing a user to perform some action with a malicious file; because
administrators should be wary of such things or even of running a browser
from a privileged account, the impact of those exploits are limited.
The seven kernel and six server exploits represent a more dangerous class,
with system compromise a distinct possibility. None of the kernel exploits
were remote and all were either denial of service or privilege escalation
bugs. Each of the server application exploits could lead to compromise
of the non-root user that runs the service.
It is interesting to note that
SELinux and
Exec-Shield
are specifically
mentioned as either eliminating or reducing the impact of eleven of these
exploits. Both of these security tools are installed by default with RHEL4
and are targeted at stopping or reducing the effectiveness of just these
kinds of attacks. Exec-Shield uses address space randomization and
protection against executing code from the stack to avoid executing
arbitrary code in the presence of a buffer overflow or similar flaw.
The SELinux policy that ships with RHEL4 restricts users and processes
to only that set of resources they need for their normal function and that
can reduce the kinds of problems an exploited process can cause.
While they are no substitute for correctly written code, these technologies
are clearly helpful to reduce security threats; with luck other techniques
will come along that continue this kind of work.
This is the second report on RHEL4 security; the
first
covers the first year of release. Based on a comment on his original
article, the author is planning a four year retrospective on RHEL3 in
November which should be interesting as well. The comment indicates
only six critical vulnerabilities in the RHEL3 default install in its three
and a half years.
It is
difficult to put a label on the level of 'security risk' that a particular
system has, but RHEL4 would seem to have a fairly low risk overall. If one
keeps up with the patches and is reasonably cognizant of security practices,
the chances for a system compromise are low. This is a real accomplishment
by the Red Hat team and should be a feather in the cap for Linux in
general. No software is perfect and an operating system or distribution
is just a collection of software so vigilance is required. Without examining
our track record, it is difficult to gauge progress and this kind of report is
an excellent way to track that progress; hopefully other distributions will
follow suit.
Comments (1 posted)
