Red Hat Magazinehttp://magazine.redhat.com
Just another WordPress.com weblogThu, 12 Feb 2015 17:34:31 +0000enhourly1http://wordpress.com/http://0.gravatar.com/blavatar/43e95982d87da9fb7c7b9a74b524335f?s=96&d=http%3A%2F%2Fs2.wp.com%2Fi%2Fbuttonw-com.pngRed Hat Magazinehttp://magazine.redhat.com
Now showing: opensource.comhttp://magazine.redhat.com/2010/01/29/now-showing-opensource-com/
http://magazine.redhat.com/2010/01/29/now-showing-opensource-com/#commentsFri, 29 Jan 2010 09:00:15 +0000http://magazine.redhat.com/?p=1467]]>Hi. We’re back. Well, not back exactly. We’d just like to take a minute to introduce you to somebody. Somebody that’s important to us.

We promised we’d let you know when we had news–and now we do. Opensource.com is our new adventure. It’s still sponsored by Red Hat, and still shining a bright light on the open source stories we’ve always sought out.

At opensource.com, we’ll be doing some things a little differently than we used to. We won’t be addressing as many technical topics–but we do hope to address more topics more often. We welcome contributions in the areas of Business, Law, Education, Government, and Life. We welcome new (and old) contributors.

And for those of you that were fond of our video contributions? Never fear. Our crack video team is fully involved.

So give it a click. Check out the articles. Sure, it’s not the same comfy digs you’d gotten used to, but pretty soon, it’ll feel just as homey. And that’s where we’ll be, for the next while.

Red Hat Magazine enjoyed a fantastic run. It’s launched careers, ideas, and helped publish–and promote–writers we dearly know and love. It gave us experience–and information–we can take to this newer, bigger venture. And now we’ve got a new venue–and a new name–to keep doing the kind of work we love. That kind of work and more.

One thing that has changed and–we think–for the better: It’s not just Red Hat’s magazine anymore. Opensource.com belongs to everyone. It’s a conversation-starter, a place for debate, and we hope you’ll come be a part of it.

And thank you. For subscribing, for contributing, and for reading–at RHM and beyond.

]]>http://magazine.redhat.com/2010/01/29/now-showing-opensource-com/feed/0The editorial teamWhere have we been?http://magazine.redhat.com/2009/09/15/where-have-we-been/
http://magazine.redhat.com/2009/09/15/where-have-we-been/#commentsTue, 15 Sep 2009 20:14:47 +0000http://magazine.redhat.com/?p=1463]]>It seems we’ve been a bit out of touch. Rather than bore you with excuses, let’s cut to the chase. Over the last year, we’ve slowed down—and then stopped altogether—publishing articles in Red Hat Magazine. And some of you have been contacting us to ask why.

There’s really a couple of reasons.

First of all, we’ve been running Red Hat Magazine a long time—under the RHM banner since November 2004. Before that we were a monthly newsletter called Under the Brim.

Point is, things change. We were once a text-only, link-heavy monthly email. Back then, we didn’t write very much original content—well, except for Shadowman. He (and his third-person narrative) have been around a while. He’s seen us publish through email, on the web—we even tried an issue in print. In the last few years, we dipped our toes into the online daily news space with both excitement and apprehension. We launched videos. We recorded podcasts. Some stuff we kept; some stuff we moved aside.

And now it’s time for another change.

We’re sorry we didn’t get around to telling you earlier. But, truth is, we weren’t quite sure what we were doing next. Some planets had to align. Some realities had to be faced. And there’s still a lot of work to be done. But we didn’t want to leave you hanging any longer.

We haven’t forgotten you. We’ve been hard at work figuring out just where we go from here. The content we have is too good to leave languishing in a corner. Our writers are too talented to not see the light of day. We’re working on delivering the open source message in a different way. There will be more info soon, and you’ll be among the first to know.

In the meantime, enjoy our archives. We’ll keep them here for now. Watch the email list for announcements. It’s been a long, strange, and wonderful trip. And it’s not over yet.

Open source is answering the call at government agencies on all levels as they look for opportunities to carve out costs and improve security, transparency, public participation, and collaboration. Why? Open source is stable, trustworthy, and secure, and Red Hat solutions are being used across government agencies to create efficiencies, eliminate vendor lock-in, meet mission-critical IT demands, and improve service delivery.

]]>http://magazine.redhat.com/2009/05/19/video-open-source-government/feed/9The editorial teamCall for submissions: Innovation Awards and RHCE of the Yearhttp://magazine.redhat.com/2009/04/28/call-for-submissions-innovation-awards-and-rhce-of-the-year/
http://magazine.redhat.com/2009/04/28/call-for-submissions-innovation-awards-and-rhce-of-the-year/#commentsTue, 28 Apr 2009 19:34:17 +0000http://magazine.redhat.com/?p=1426]]>It’s that time of year again–the Red Hat Summit and JBoss World are fast approaching, and with them, Red Hat’s annual awards ceremonies. But first, we need nominations. And for that we appeal to our customers, readers, partners, and friends. That’s you.

Nominate that innovative business you worked with, or the admin who always has the right answers. Winners will receive free admission to Red Hat Summit and JBoss World, participation in exclusive events, and the admiration and accolades of their peers. Here’s the details:

2009 Innovation Awards – Nominations Open

Nominations are now open for the 2009 Innovation Awards, to be presented at this year’s co-located Red Hat Summit and JBoss World on September 1-4, 2009 in Chicago.

Innovation Awards were created to recognize technological achievements that demonstrate creative thinking and determined problem solving. The program includes the Extensive Ecosystem category which was created to recognize customers who are working with Red Hat and JBoss partners to create innovative architectures based on open source solutions. Please submit nominations by the deadline of May 31, 2009.

Innovation Award Categories: Five categories will each recognize two winning projects, one from Red Hat and one from JBoss. The Outstanding Open Source Architecture category will recognize one winner who is deploying both Red Hat and JBoss solutions. From these category winners, a Red Hat Innovator of the Year
and a JBoss Innovator of the Year will be selected by the community through online voting and announced at the awards ceremony.

Managed Excellence

Recognition of the impressive use of management tools, including Red Hat Network® and JBoss Operations Network®, to drive down total cost of ownership (TCO) and increase the return on investment (ROI).

Outstanding Open Source Architecture

2009 RHCE of the Year

Red Hat Certified Engineer of the Year contest is a celebration of the hard work, expertise, and ingenuity of some of the world’s premier IT professionals.

If you are an RHCE®, now is your chance to wow us with why you should be selected as an 2009 RHCE of the Year. Maybe you’re administering 100 different boxes. Maybe you’ve solved an insurmountable problem. No doubt, you’ve got talent. Now is the time to prove it.

The five winners will get a free trip to the 2009 Summit in Chicago, September 1-4, 2009. The award includes three nights of accommodations, round-trip coach airfare, conference registration cost, and Chicago-style entertainment each night. The winners will also receive a 2009 RHCE of the Year plaque and will be honored at the RHCE Summit Reception.

So what’s the big deal? Why all the fuss? Here’s just a few of the improvements wrought by the combination of Intel’s processing power and Red Hat advancements in performance and efficiency.

Improved performance

According to Stream performance data, the new Intel Xeon 5500 series processor delivers a 2.25 times performance improvement, when compared to the performance of the preceding processor series (the Intel Xeon 5400). This allows the new processor to handle datacenter workloads at nearly twice the efficiency.

Intelligent performance

The processor can dynamically adapt throughput to the workload. Intel Hyper-Threading Technology lets system administrators increase workloads and add capabilities without slowing the system down—there’s plenty of reserve for usage peaks. Expanded physical server limits in Enterprise Linux 5.3 (255 CPUs and 1 TB main memory) improve system scalability dramatically.

Virtualization

Red Hat Enterprise Linux and Intel Virtualization Technology (Intel VT) deliver high consolidation ratios. These virtualization enhancements provide greater scalability and performance, and allow for the virtualization of a wide range of workloads, even those that are I/O intensive.

Automated energy efficiency

The combination of technologies supports low-latency changes between power states. This can help lower power consumption during off-peak hours . Integrated power gates and memory controllers deliver energy efficiency from the hardware side, while enhanced power management and CPU clock frequency scaling help conserve power from the Red Hat Enterprise Linux side.

Red Hat and Intel have a long history of working together to take open source technology to its full potential. Whether it’s combined open source contributions or corporate partnerships, the x86 platform and the open source software revolution have changed the face of computing. Integrated virtualization—and continued rapid improvements in processor technology—keeps the changes coming.

Python has a simple solution for building modules, applications, and extensions called distutils. Disutils comes as part of the Python distribution so there are no other packages required.

Pull down just about any python source code and you’re more than likely going to find a setup.py script that helps make building and installing a snap. Most engineers don’t add functionality when using distutils, instead opting to use the default commands.

In some cases, developers might provide secondary scripts to do other tasks for building and testing outside of the setup script, but I believe that can lead to unnecessary complication of common tasks.

For those who are not familiar with setup scripts, Figure 1 shows a simple example.

This setup script lists the metadata, maps to a package directory, and provides the general commands expected from distutils setup. This is great, but as I’ve said, it may not do everything you need it to.

What if, for example, we want to be able to see all the TODO tags in the codebase on any platform? In other words, grep won’t cut it.

Let’s start by writing a function that searches for TODO tags in files and prints them back to the screen in a nice format like:

src/myapp/__init__.py (11): TODO: remove me

def report_todo():
"""
Prints out TODO's in the code.
"""
import os
import re
# The format of the string to print: file_path (line_no): %s line_str
format_str = "%s (%i): %s"
# regex to remove whitespace in front of TODO's
remove_front_whitespace = re.compile("^[ ]*(.*)$")
# Look at all non pyc files from current directory down
for rootdir in ['src/', 'bin/']:
# walk down each root directory
for root, dirs, files in os.walk(rootdir):
# for each single file in the files
for afile in files:
# if the file doesn't end with .pyc
if not afile.endswith('.pyc'):
full_path = os.path.join(root, afile)
fobj = open(full_path, 'r')
line_no = 0
# look at each line for TODO's
for line in fobj.readlines():
if 'todo' in line.lower():
nice_line = remove_front_whitespace.match(
line).group(1)
# print the info if we have a TODO
print(format_str % (
full_path, line_no, nice_line))
line_no += 1

Figure 2.

The report_todo function is self-contained and quite simple, if a bit clunky by itself. Who wants to install and use a ‘report-todo’ command on machines just to look for TODO tags?

We want to turn this into a setup command so that we can ship it with our application ‘myapp’ to be used by developers via setup.py. We will probably add more setup commands in the future, so let’s create a class to subclass our commands from. We do this because most of our commands will probably be simple and won’t need to override the *_option methods (though they can if they need to).

The SetupBuildCommand defines a few methods that are required for all setup commands. As I stated before, most of our commands will probably not deviate from these defaults, so defining them higher in the object hierarchy means simpler code in the commands themselves. If we do want to add arguments to to any of our commands, we can override initialize_options() and finalize_options() to handle the arguments properly.

Now that we have the SetupBuildCommand to subclass from we can merge our report_todo function into a SetupBuildCommand class. To do this, we create a class that subclasses SetupBuildCommand, and then add a description variable and a run method (which is what is executed when the command runs).

class TODOCommand(SetupBuildCommand):
"""
Quick command to show code TODO's.
"""
description = "prints out TODO's in the code"
def run(self):
"""
Prints out TODO's in the code.
"""
import re
# The format of the string to print: file_path (line_no): %s line_str
format_str = "%s (%i): %s"
# regex to remove whitespace in front of TODO's
remove_front_whitespace = re.compile("^[ ]*(.*)$")
# Look at all non pyc files in src/ and bin/
for rootdir in ['src/', 'bin/']:
# walk down each root directory
for root, dirs, files in os.walk(rootdir):
# for each single file in the files
for afile in files:
# if the file doesn't end with .pyc
if not afile.endswith('.pyc'):
full_path = os.path.join(root, afile)
fobj = open(full_path, 'r')
line_no = 0
# look at each line for TODO's
for line in fobj.readlines():
if 'todo' in line.lower():
nice_line = remove_front_whitespace.match(
line).group(1)
# print the info if we have a TODO
print(format_str % (
full_path, line_no, nice_line))
line_no += 1

Figure 4.

The run method in this example is the same as report_todo but in a method format (with self) and renamed to run.

Now it’s time to bring all this together. If we add Figure 1 and Figure 2 to the setup script (Figure 1), then all that is left is to map the setup command with a command name. Do this via the cmdclass argument, and in the form:

John “J5″ Palmieri explains how the Fedora community–codename MyFedora–is bringing Fedora users together by integrating self-contained applications into a single framework application. This interface enables Fedora users to see and keep track of what applications other community members are working with.

]]>http://magazine.redhat.com/2009/04/03/video-spotlight-on-my-fedora/feed/5The editorial teamHappy Document Freedom Dayhttp://magazine.redhat.com/2009/03/25/happy-document-freedom-day/
http://magazine.redhat.com/2009/03/25/happy-document-freedom-day/#commentsWed, 25 Mar 2009 15:23:43 +0000http://magazine.redhat.com/?p=1191]]>Document Freedom Day (DFD) is a global grassroots effort to promote and build awareness of the importance of free document formats in particular and open standards in general. If you have ever received a document from a friend that your software could not open, then you know the frustration of proprietary formats. Document Freedom Day promotes open formats so that users can freely exchange their data no matter what software program they choose to use. Complete interoperability is the ultimate goal of those who support open standards.

And it’s not just a matter of convenience. Public documents stored on closed, proprietary formats require citizens to pay twice to access information that already belongs to them, once for the document creation, and again to access them. There is also the danger of losing the information stored in those formats should the vendors go out of business, or decide that they no longer want to maintain that technology. Proponents of open document formats believe all public information should be stored using open standards accessible to all.

Melanie Chernoff, Red Hat’s Public Policy Manager explains that “Red Hat is committed to open source, open standards and open content. Document Freedom Day is an opportunity to single out one of these important areas, open standards. DFD promotes open standards in the document space, which is where the average user really feels the impact of proprietary formats.

“We view Document Freedom Day as a great vehicle for highlighting the importance of standards to interoperability and user choice, which reflect Red Hat’s core values. ”

Sometimes open source ideals make for the strangest–and most wonderful–bedfellows. We met Dr. Vandana Shiva–physicist, scientist, environmentalist, and activist–several years ago. Her work saving seeds and protecting traditional knowledge in the farming industry parallels the openness, transparency, collaboration and freedom of open source ideology. Her simple, clear explanation of why knowledge should be shared–and the devastating results should it be hoarded–is part of the essential truth that makes the work we do so incredibly important. But don’t take our word for it.

]]>http://magazine.redhat.com/2009/03/20/video/feed/7The editorial teamRisk report: Four years of Red Hat Enterprise Linux 4http://magazine.redhat.com/2009/03/10/risk-report-four-years-of-red-hat-enterprise-linux-4/
http://magazine.redhat.com/2009/03/10/risk-report-four-years-of-red-hat-enterprise-linux-4/#commentsTue, 10 Mar 2009 22:06:47 +0000http://magazine.redhat.com/?p=1162]]>Red Hat® Enterprise Linux® 4 was released on February 15th, 2005. This report takes a look at the state of security for the first four years from release. We look at key metrics, specific vulnerabilities, and the most common ways users were affected by security issues. We will show some best practices that could have been used to minimise the impact of the issues, and also take a look at how the included security innovations helped.

1. Introduction

We measure the overall risk of running Enterprise Linux 4 as a function of two factors; the vulnerabilities and the threats. Our first section covers the security vulnerabilities found in packages that are part of Enterprise Linux 4 and the advisories that address them. Our second section covers the threats by examining actual exploitation of those vulnerabilities through exploits and worms.

All the data used to generate this report, tables, and graphs, apply to Red Hat Enterprise Linux 4 AS from release day, 15 February 2005 to 14 February 2009 unless otherwise stated.

2. Vulnerabilities

At first sight it may appear that Red Hat have released a lot of updates for Enterprise Linux 4; in the last twelve months publishing a total of 107 security advisories to address 251 individual vulnerabilities. But in reality this is by far a worst-case metric, as it treats all vulnerabilities as equal, regardless of their severity and assumes a system that has installed every available package – which is not a default or even a likely installation.

With the release of Enterprise Linux 4, we started publishing severity levels with package errata to help users determine which advisories were the ones that mattered the most. Providing a prioritised risk assessment helps customers to understand and better schedule upgrades to their systems, being able to make a more informed decision on the risk that each issue places on their unique environment. Red Hat rates the impact of individual vulnerabilities on a four-point scale designed to be an at-a-glance guide to how worried Red Hat is about each security issue.

2.1. Vulnerability Counts

There are four variants of Red Hat Enterprise Linux 4; two targeted at server solutions with Enterprise Linux AS and ES, and two targeted at client solutions with Enterprise Linux WS and Red Hat Desktop. The package set available in Enterprise Linux WS and Red Hat Desktop is a subset of that available in Enterprise Linux AS.

During Enterprise Linux 4 installation, the user gets a choice of installing either the default selection of packages, or making a custom selection. Table 2 shows the vulnerability counts, normalised by CVE name, for some selected configurations.

Severity

Enterprise Linux 4 ASdefault install

Enterprise Linux 4 WSdefault install

Enterprise Linux 4 ASall possible packages

Critical

10

126

130

Important

267

320

360

Moderate

211

350

484

Low

151

184

295

Total

639

980

1269

Table 2. Vulnerabilities by severity, 4 years

A default install of Enterprise Linux 4 AS was only vulnerable to ten critical flaws in the whole four years. This is because most of the critical flaws have been in web browsers and their plug-ins: Firefox and Mozilla/SeaMonkey packages are not installed by default on distributions intended for server systems.

Client systems (Enterprise Linux WS and Red Hat Desktop) do include Firefox, Mozilla, and Helixplayer by default, leading to 126 critical vulnerabilities. A custom installation of AS, selecting every available package, would yield a system affected by the maximum possible number of critical vulnerabilities for the four years, 130.

For the purposes of this study we consider the worst-case scenario, a version of Red Hat Enterprise Linux 4 obtained on the day of release. During the first four years, six Update releases were made (Update 1 in June 2005, Update 2 in October 2005, Update 3 in March 2006, Update 4 in August 2006, Update 5 in May 2007, Update 6 in November 2007, Update 7 in July 2008). The Update releases are similar to a “service pack” and contain a roll-up of all security advisories. So, for example, a user who installed Enterprise Linux 4 in August 2008 would use Update 7 and be affected by only a subset of the issues. We’ve also counted vulnerabilities not advisories; it’s usual for a single security update of a package to fix a number of vulnerabilities at the same time, so the number of advisories and updates needed to be installed is far lower.

Tip

You can cut down the number of security issues you need to deal with by carefully choosing the right Enterprise Linux variant and package set when deploying a new system, and ensuring you install the latest
available Update release.

2.2. Critical Flaws

Vulnerabilities rated critical severity are the ones that can pose the most risk to an organisation. By definition, a critical vulnerability is one that could potentially be exploited remotely and automatically by a worm. However we also stretch the definition to include those flaws that affect web browsers or plug-ins where a user only needs to visit a malicious (or compromised) web site in order to be exploited. Since the vast majority of critical severity issues occurred due to web browsers or plugins, this is why there is such a difference between the number of critical issues that affects a default install of Enterprise Linux 4 AS and WS.

For the purposes of the severity classification we ignore what privileges the attacker would be able to gain: a remote root compromise via something like Samba would be of a much higher risk than a user-complicit Firefox flaw that results in running code as an unprivileged user, but both would be rated as critical on this scale.

To help qualify the risk we’ve split up the critical vulnerabilities into those that require some minimal user interaction to be exploitable (such as if a user visits malicious web page), and those that require no user interaction at all (and therefore could potentially be exploited by a worm).

For Enterprise Linux 4 AS with every package installed, Table 3 summarises all critical issues, and Table 4 breaks out the critical, non-browser flaws.

Mitigate an intrusion into certain Red Hat computers where a small number of signed tampered packages were created but not distributed on Red Hat Network. Classified critical to ensure any tampered packages would be
replaced with official ones.

We’ve included in these tables the “days of risk” metric. This is commonly defined as the number of calendar days it takes for a vendor to produce updates that correct a flaw after the flaw is first known to the public.

Fixes for 87% of critical flaws were available from Red Hat Network the same day or next calendar day after public disclosure of the flaw. This fast response time is a deliberate goal of the Red Hat Security Response Team and forms an essential part of reducing customer risk from critical flaws.

2.3. Expanding “days of risk”

The “days of risk” metric has it’s limitations and so it isn’t particularly useful for comparing different software vendors against each other. The software that makes up the Enterprise Linux 4 distribution is open source, so we’re not the only vendor shipping each particular application. Unlike companies shipping proprietary software, Red Hat is not in sole control over the date each flaw is made public. This is actually a good thing and leads to much shorter response times between flaws being first reported to being made public. It also keeps us honest; Red Hat can’t play games to artificially reduce our #8220;days of risk” statistics by using tactics such as holding off public disclosure of important flaws for a long period, or until some regularly scheduled patch day.

A more useful metric to help assess risk would also take into account the amount of time that each issue was known to the vendor in advance. As part of our security measurement work since Enterprise Linux 4 we’ve been tracking how the Red Hat Security Response Team first found out about each vulnerability we fix. This information is interesting as it can also show us which relationships matter the most to us, and identify trends in vulnerability disclosure.

For each of the 1269 total vulnerabilities, across every package in Enterprise Linux in the 4 years, we determined if the flaw was something we knew about a day or more in advance of it being publicly disclosed, and how we found out [1] about the flaw. The results are summarised in Figure 2 and Figure 3.

Figure 2. Source of vulnerabilities known in advance

Figure 3. Source of vulnerabilities already public

Red Hat knew about 51% of the security vulnerabilities that we fixed at least a day in advance of them being publicly disclosed. For those issues, the average notice was 21 calendar days, although the median was much lower, with half the private issues having advance notice of 9 days or less. Figure 4 shows the distribution of notice periods in more detail.

Figure 4. How much time in advance Red Hat knew about issues before they were publicly disclosed

2.4. Riskiest packages

In our work tracking and fixing vulnerabilities it sometimes seems like we produce a security advisory for the same packages every month. We therefore analysed Enterprise Linux 4 to find out which packages were
responsible for the most vulnerabilities, weighting them [2] to take into account their severity. The results are shown in Table 5, which lists the top 10, ranked across all four years.

Rank

Package

Critical

Important

Moderate

Low

1

mozilla/seamonkey

100

22

86

18

2

firefox

94

31

87

22

3

thunderbird

46

22

106

12

4

kernel

0

115

59

34

5

HelixPlayer

7

0

1

0

6

cups

0

23

9

1

7

samba

4

2

3

0

8

krb5

2

10

3

2

9

php

0

14

22

25

10

evolution

3

3

8

4

Table 5. Top 10 packages with the worst security history, 4 years

These top 10 packages together totaled 79% of all the weighted vulnerabilities. The kernel, cups, php, krb5, and samba packages are part of the default installation of Enterprise Linux 4 AS.

Tip

You can reduce the number of vulnerabilities that will affect your systems by removing packages that you don’t need or don’t use, particularly those that have the worst security history. For example, if you don’t use thunderbird on a machine you could just remove the package.

2.5. Advisory Workload

In previous reports we’ve graphed the vulnerability workload, a measure of the number of vulnerabilities that security operations staff would need to worry about every day, weighted by severity. But the actual effort in maintaining an Enterprise Linux system is more related to the number of advisories we released, rather than the number of vulnerabilities: A single Firefox advisory may fix ten different issues of critical severity, but takes far less total effort to manage than ten separate advisories each fixing one critical Samba vulnerability.

Our Advisory Workload index gives a measure of the number of important advisories that users would need to worry about every day. The higher the number, the greater the workload, and the greater the general risk represented by the vulnerabilities addressed. This workload index is calculated in a similar way to the NIST workload index.

For a given month, Advisory Workload = weighted number of advisories [3] / days in the month. A workload of 1.0 would mean one important advisory a day.

Figure 5. Advisory Workload

Figure 5 shows the advisory workload index for a installation of Enterprise Linux 4 including every package. The initial peak during the first month looks surprising, but is easily explained, as the packages for Enterprise Linux 4 had a code freeze a few months prior to release. This led to a backlog of security issues that were fixed with updates on the date of release. The small peak in August 2005 aligns with the release of Update 1, and the other peaks align with Update releases or months during which there were several Firefox and SeaMonkey
updates.

Tip

Cut down on the number of alerts you receive. Register your systems with the Red Hat Network to get customised notifications for security updates for the packages your systems have installed. If you want to see all security updates for every Enterprise Linux version and package, subscribe to enterprise-watch-list mailing list as well.

3. Threats

The first part of this report analysed the total vulnerabilities found affecting Enterprise Linux 4. But to get a better evaluation of platform risk we also need to take into account the threat. This part therefore looks at
exploits and worms written to take advantage of the vulnerabilities.

Red Hat is continually developing technologies to help reduce the risk of security threats, and a number of these were consolidated into Red Hat Enterprise Linux 4. The most significant technologies were SELinux and
Exec-Shield. Exec-Shield is a project which includes support for the No eXecute (NX) memory permission, simulating NX via segment limits, Position Independent Executables (PIE), gcc, and glibc hardening. For more details, a table of the major security technology innovations in Enterprise 4 is available.

3.1. Exploits

An exploit is the way that an attacker makes use of a vulnerability. The Red Hat Security Response Team monitor numerous sources to track which vulnerabilities are being exploited. For this report we compiled a list of the publicly available exploits for the vulnerabilities that affected the first four years of Enterprise Linux 4.

We are interested in those exploits that have the potential to cause remote damage to the confidentiality or integrity of a system and we therefore don’t include exploits for vulnerabilities that are limited to a denial of service (affecting availability). We do, however, include exploits which are labeled “proof of concept”. A proof of concept exploit may only cause a crash or not quite work properly without modification, but in theory the vulnerability could be exploited properly leading to greater consequences. These proof of concept exploits often show techniques that a skilled attacker can turn into a full exploit.

We found exploits for 59 vulnerabilities for the first four years. 24 (40%) of these exploits are for buffer overflow vulnerabilities where in most cases the Exec-Shield technology should help prevent remote exploitation due to protections such as ASLR and enforcement of a non-executable stack.

3.1.1. Kernel exploits

The public exploits for the Linux kernel lead to one of two consequences: either a local unprivileged user can cause the machine to crash, or a local user can gain privileges.

We found exploits for nine vulnerabilities that had the potential to allow an unprivileged user to gain privileges on an unpatched Enterprise Linux 4 system. Of the nine, one required the target system to be using bluetooth drivers (CVE-2005-0750), another was exploitable only on systems with more than one CPU (CVE-2005-0001), one affected only x86_64 architectures (CVE-2007-4573), and one required a writable sgid directory (CVE-2008-4210).

The remainder (CVE-2006-3626, CVE-2006-2451, CVE-2005-0736, CVE-2004-1235, and CVE-2005-0531) could work on any default, unpatched system. Some of those exploits need unpublished source code adjustments in order to work against an Enterprise Linux 4 kernel.

3.1.2. Browser exploits

Around of quarter of the public exploits we found were for flaws in web browsers; and all but three targeted the Mozilla suite (Mozilla, Firefox, Thunderbird). These are detailed in Table 6. For each exploit, any resultant code execution would be limited to being run with the same rights as the user that is running the vulnerable browser. It is best practice to never use a web browser or email client as root. Some of these exploits are also blocked if JavaScript is disabled.

Vulnerabilities

Description

CVE-2005-0399

An exploit for a flaw where a malicious GIF image could cause an overflow. This issue is more serious in Thunderbird, where opening a malicious email could trigger this flaw.

CVE-2006-0295, CVE-2005-2871

Exploits for flaws where a malicious web page could run arbitrary code. The public exploit for CVE-2005-2871 was designed for Windows platforms, exploiting this flaw on Linux would require different techniques.

Exploits for flaws where a malicious web page could run arbitrary JavaScript, doing things like changing home pages, stealing cookies, cross-site scripting, or creating files on the system.

CVE-2005-2262, CVE-2005-2269

Exploits for two user-complicit overflow flaws that require the victim to use the ’set as wallpaper’ option on a malicious image.

CVE-2006-3677

An exploit for a JavaScript code flaw. This could result in the execution of arbitrary code if a victim visits a malicious website.

CVE-2007-0981

An exploit that can bypass the same-origin policy, allowing cookie or cross-domain attacks.

CVE-2005-2710

An exploit for a format-string vulnerability in HelixPlayer. HelixPlayer can run as a web browser applet potentially allowing code execution.

CVE-2005-3120

An exploit in the Lynx optional text-based browser. The public exploit is a proof of concept only.

CVE-2006-5925

An exploit in the Links text web browser which could allow arbitrary commands to be executed if a victim visits a malicious web site.

Table 6. Exploits for browser flaws

3.1.3. Other user-complicit exploits

The next class of exploits are those we term ‘user-complicit’, in that they need some involvement from the victim to be exploited. Some examples of user involvement would be opening a malicious file with a vulnerable application, or viewing an instant message from an unknown user. Table 7 lists the exploits we discovered that require some user involvement.

Vulnerabilities

Description

CVE-2008-2383

An exploit for a flaw in xterm. An attacker could create a malicious text file (or log entry, if unfiltered) that could run arbitrary commands if read by a victim inside an xterm window.

CVE-2008-2292

Proof of concept DoS exploit for a buffer overflow in the Perl bindings for Net-SNMP. This could be triggered if an attacker could convince an application using the Net-SNMP Perl module to connect to a malicious SNMP agent.

CVE-2008-1801

Proof of concept DoS exploit for an integer underflow flaw in rdesktop. If an attacker can convince a victim to connect to a malicious RDP server, the attacker could cause the victim’s rdesktop to crash or possibly execute arbitrary code

CVE-2008-1105

Proof of concept DoS exploit for a heap overflow in Samba. If an attacker can convince a victim to connect to a malicious server, the attacker could cause the client to crash or possible execute arbitrary code

CVE-2007-3103

An exploit for a flaw in X.Org font server. If a local attacker can get the xfs service to be restarted by root they could gain privileges.

CVE-2007-2356

An exploit for a stack buffer flaw in the Gimp image editor. If an attacker can force a victim to run the Gimp on a malicious image they could execute arbitrary code as the victim.

CVE-2006-2656

An exploit for a flaw in libtiff. If an attacker can force a victim to run the ‘tiffsplit’ executable with a malicious filename they could cause code to run as that user. This is low severity as nothing we ship
runs ‘tiffsplit’ with an arbitrary filename.

CVE-2006-1542

An exploit for a flaw in Python. This is a low severity issue as the user would need to be tricked into running python with a very long script name, an unlikely scenario.

CVE-2005-3243, CVE-2005-2367, CVE-2005-1461, CVE-2005-0699

Exploits for several vulnerabilities in Ethereal/Wireshark. In order to be exploited a victim with privileges would have to be analysing network packets using Wireshark from a network into which an attacker could inject carefully crafted malicious packets. The protocols affected by the vulnerabilities (SLIMP3, AFP, SIP, and RADIUS) are unlikely to be allowed through a border firewall, so the ability to exploit this flaw remotely is restricted.

CVE-2005-1704

An integer overflow could allow a malicious executable to execute arbitrary code. This is low severity as the attacker needs to convince the victim to run the malicious binary (and a malicious binary could perform arbitrary actions anyway).

CVE-2005-1261

Proof of concept DoS exploit for a flaw in the Gaim instant-messaging client. For some protocols, an attacker could send a carefully crafted message which could trigger the flaw and cause code execution.

CVE-2005-0156

An exploit for a flaw in the setuid Perl package. Where perl-setuid is installed, an unprivileged local user could gain root privileges. The exploit as published needs minor changes to work on unpatched Enterprise Linux 4 systems.

Table 7. Exploits for user-complicit flaws

3.1.4. PHP exploits

During March 2007 the “Month of PHP bugs” uncovered a number of issues, some of which affected the PHP packages as distributed with Enterprise Linux 4. The PHP interpreter does not offer a reliable sand-boxed security layer (as found in, say, a JVM) in which untrusted scripts can be run, so any script run by the PHP interpreter must be trusted with the privileges of the interpreter itself. Therefore, in analysis of these issues, exploits which relied on an “untrusted local attacker” were not classified as security-sensitive since no trust boundary was crossed.

This leaves us with the exploits shown in Table 8. These exploits rely on the victim having PHP scripts installed that use the vulnerable PHP functions in a particular way or with untrusted data. In each case the default SELinux targeted policy for Apache would restrict what a successful exploit is able to do.

Vulnerabilities

Description

CVE-2007-1286

Exploit for a flaw in the unserialize function. Although unserialize is used by some PHP scripts with untrusted data, the input string required to exploit this issue must exceed ~512K in length, so default Apache line length limits will prevent this from being remotely exploited via input data carried in the HTTP request headers or URI.

CVE-2007-1287

Exploit for a cross-site-scripting issue in the phpinfo function. Generally, the phpinfo function should never be used in publicly-accessible PHP scripts.

CVE-2007-1701

Exploit for a flaw in the session extension which allows super-globals to be over-ridden by an attacker, exploitable if session data is taken from an untrusted source.

CVE-2007-1718

Exploit for a flaw in the mail function which could allow a remote attacker to inject arbitrary headers into PHP generated mail if the mail Subject comprises of user-supplied data.

CVE-2007-1885

Exploit for an integer overflow in the str_replace function, which can be triggered remotely if a script passes large untrusted strings to particular arguments of this function.

CVE-2007-0906

Exploit for a heap overflow in the imap_mail_compose function, which can be triggered if a script uses the function to create a new MIME message based on an input body from an untrusted source.

CVE-2006-4020

Exploits for a flaw in the sscanf function. If a PHP script passed data under an attackers control to sscanf it could result in a buffer overflow.

CVE-2005-1921, CVE-2005-2498

Exploits for flaws in the PEAR XML-RPC code. These exploits require a server to be running a third-party PHP application that exports an XML-RPC interface.

Table 8. Exploits for PHP flaws

3.1.5. Servers and services exploits

Our final class of exploits are those that affect server applications and services, in Table 9. These are the most serious threats.

Vulnerabilities

Description

CVE-2008-2936

An exploit for a flaw in Postfix. A local attacker could gain root privileges in the unlikely event they have write access to a mail spool directory with no root mailbox.

CVE-2008-1891

An exploit for a Ruby WEBrick flaw. A remote attacker could read arbitrary CGI files, but only if the files were being served from a NTFS or FAT filesystem.

CVE-2008-0960

An exploit to bypass authentication in Net-SNMP. A remote attacker could cause the execution of arbitrary commands if they can connect to a system using Net-SNMP.

CVE-2008-1447, CVE-2007-2926

Problems with BIND not having sufficient randomisation. Exploits were released to use these flaws to poison the DNS cache.

CVE-2007-0957

An exploit for a buffer overflow in the Kerberos administration daemon. A remote authenticated user could execute arbitrary code as root on the Kerberos server.

CVE-2007-6015

An exploit for a buffer overflow in Samba. In order to exploit this flaw, the “domain logons” option would need to be enabled.

CVE-2005-0022

A remote exploit for a buffer overflow in the non-default Exim mail server which could lead to arbitrary code execution as the ‘exim’ unprivileged user. In order to exploit this vulnerability, Exim needs to be installed and SPA authentication specifically enabled, which is not a usual configuration.

CVE-2005-0710, CVE-2005-0709

Exploits for flaws in the MySQL server. A remote authenticated user with privileges to insert or delete from a database table could execute arbitrary code on the MySQL server as the unprivileged ‘mysql’ user. The default SELinux targeted policy for MySQL would restrict what a successful exploit is able to do.

Table 9. Exploits for flaws in servers and services

Tip

The way to reduce your risk from exploits is to make sure your systems have all applicable security updates installed. The Red Hat Network can help keep track of this.

3.2. Worms

Worms take advantage of vulnerabilities in order to compromise systems, then use the compromised system to seek out other systems to infect. By our definition, any vulnerability that could be exploited in this way would be classed as severity critical. In the first section of this report we listed every vulnerability that was rated as critical severity and showed that only a subset of those vulnerabilities could be actually used by worms. This is because we also class as critical some browser vulnerabilities where a victim has to take action (for example visiting a malicious web page) and therefore are not exploitable by a worm.

Worms affecting Linux platforms have been quite scarce in the last few years, and the anti-virus vendors who track malware recorded only two (although some variants of each exist) during the four year period of this study:

Linux/MARE was discovered in November 2005 and was a worm that spread by exploiting a flaw in PHP-Nuke. PHP-Nuke is not shipped as part of Red Hat Enterprise Linux.

Linux/Lupper was also discovered in November 2005 and was a worm designed to exploit CVE-2005-1921, a flaw in the PHP PEAR XML-RPC server package exploitable through a number of third party PHP applications. None of the affected third-party applications were shipped as part of Red Hat Enterprise Linux. Additionally, a PHP update in July 2005 fixed the underlying flaw in PHP. Even users that had not patched were also protected from this worm by the default SELinux configuration.

Without critical vulnerabilities to allow attackers to remotely exploit machines, we saw attackers instead try to focus on exploiting weak configurations. During the period of this study we tracked attempts by attackers to exploit machines with stolen passwords and brute-force password tools. The tools simply looked for internet-accessible SSH services they could connect to, then tried to log in with lots of combinations of common usernames and passwords. Restricting access to SSH remotely, moving the SSH daemon to a different port, and making sure all your users have strong passwords or use key authentication are all useful defenses against this particular attack.

4. Conclusion

The aim of this report was to get a measure of the security risk to users of Red Hat Enterprise Linux 4 during the first four years since release. We’ve shown that although on the surface it looks like Red Hat released a large number of security advisories, many of them do not apply to usual or default installations, and only a very small subset are a high risk. We’ve shown:

A default installation of Enterprise Linux 4 AS was vulnerable to ten critical security issues over the first four years

A customised installation of Enterprise Linux 4, selecting every package, would have been vulnerable to 114 critical browser security issues, and 16 in non-browser packages in the four years. 87% of those vulnerabilities had fixes to correct them available from the Red Hat Network within one calendar day of them being known to the public

Red Hat knew about 51% of security issues affecting the first four years of Enterprise Linux 4 in advance. The average time between Red Hat knowing about an issue and it being made public was 21 days (median 9
days)

We found public exploits for 59 vulnerabilities that could have affected a customised full installation, although the majority relied on user interaction or non-default settings. Attempts to use many of the exploits would be caught by standard Enterprise Linux 4 security innovations

The most likely successful exploits allowed a local unprivileged user to gain root privileges on an unpatched Enterprise Linux 4 machine

Two worms targeting Linux systems were found during the four years, but both affected third party PHP applications not shipped in Red Hat Enterprise Linux 4. In addition, an update to PHP released over three months before one of the worms was released protected systems that had installed the third party applications

It would be foolish to draw conclusions about the future state of security in Red Hat Enterprise Linux 4 solely on the basis of this analysis of the past, however what we’ve tried to do is to enumerate the level of vulnerability and threat and hence overall platform risk. Red Hat treats vulnerabilities in our products and services seriously and the policies of the Red Hat Security Response Team are specifically designed to reduce the risk from security vulnerabilities:

We place an emphasis on providing the fastest possible, highest quality, turnaround for critical vulnerabilities. We have a Security Response Team distributed globally which can draw on significant Engineering and Quality resources to get the things that matter the most fixed quickly

We release updates for critical and important security issues as soon as possible rather than batching them into monthly or quarterly updates

We provide transparency in the handling of vulnerabilities, our methods, and our metrics

All of the raw data used to generate the statistics in this report along with some tools to analyse them are available from the Red Hat Security Response Team. We also provide other tools and data that can help security measurement including CVE mappings for all our advisories and OVAL definitions.

6. About the author

Mark J Cox lives in Scotland and is Director of Red Hat Security Response. Over the last 14 years, Mark has developed software and worked on the security teams of some of the most popular open source projects including Apache, mod_ssl, and OpenSSL. Mark is a founding member of the Apache Software Foundation and the OpenSSL project, and a board member of the Mitre CVE project. In his spare time he finds geocaches with his family and occasionally plays music.

[1] We count the first place that the security team heard about a security issue. ‘Peer vendors’ are other distributors of open source software who are part of vendor-sec. ‘Upstream relationship’ covers issues told to us because we work on the upstream
projects or they contacted us to tell us about an issue. ‘Red Hat discovered’ are issues Red Hat employees discovered. ‘Red Hat notified’ are where some customer, researcher, or other third party told us about an issue through email, bugzilla, or other means. ‘Security Lists’ includes public lists like Bugtraq and Full-Disclosure,
‘CVE feed’ is a Mitre feed of newly allocated CVE names for public issues.

[2] To rank the riskiest packages we use a weighting of “Critical + Important/5 + Moderate/25 + Low/100″

[3] To weight the effort of dealing with advisories, Critical and Important advisories are scored as 1.00, Moderate advisories as 0.20, and Low advisories as 0.05. This is designed to be similar to the way that NIST calculate their workload metrics.

]]>http://magazine.redhat.com/2009/03/10/risk-report-four-years-of-red-hat-enterprise-linux-4/feed/4Mark CoxA graph showing the information sourcesA graph showing the information sourcesA graph showing the time Red Hat knew about issues in advanceA graph showing the workload index decrease from an initial high to a low average over the 4 years