해결사 박정호 학과장
Risk report: Two years of Red Hat Enterprise Linux 4
by Mark Cox
RedHat� Enterprise Linux� 4 was released on February 15th, 2005. Thisreport takes a look at the state of security for the first two yearsfrom release. We look at key metrics, specific vulnerabilities, and themost common ways users were affected by security issues. We will showsome best practices that could have been used to minimise the impact ofthe issues, and also take a look at how the included securityinnovations helped.
This report is an update to the risk report published in the March 2006 issue of Red Hat Magazine[1].
- 1. Introduction
- 2. Vulnerabilities
- 3. Threats
- 4. Mitigation
- 5. Conclusion
- 6. Further Reading
- 7. About the Author
- 5. Conclusion
1. Introduction
The overall risk of running Enterprise Linux 4 is a function of twofactors; the vulnerabilities and the threats. Our first sectiontherefore covers the security vulnerabilities found in packages thatare part of Enterprise Linux 4. Our second section covers the threatsby examining actual exploitation of those vulnerabilities throughexploits and worms.
All the data used to generate this report applies to Red HatEnterprise Linux 4 AS from release day, February 15, 2005 throughFebruary 14, 2007 unless otherwise stated.
2. Vulnerabilities
At first sight it may appear that Red Hat released a lot of updates[2]over the last 24 months, publishing a total of 289 security advisoriesto address 713 individual vulnerabilities. But in reality this is byfar a worst-case metric, as it treats all vulnerabilities as equal,regardless of their severity and assumes a system that has installedevery available package - which is not a default or even a likelyinstallation.
- Tip
- Cut down on the number of alerts you receive. Register your systemswith the Red Hat Network to get customized notifications for securityupdates for the packages your systems have installed. If you want tosee all security updates for every version and package, subscribe tothe enterprise-watch-list mailing list[3] as well
With the release of Enterprise Linux 4, we started publishingseverity levels with package errata to help users figure out whichadvisories were the ones that mattered the most. Providing aprioritised risk assessment helps customers to understand and betterschedule upgrades to their systems, being able to make a more informeddecision on the risk that each issue places on their unique environment.
Red Hat rates the impact of individual vulnerabilities on a four-point scale[4]designed to be an at-a-glance guide to how worried Red Hat is abouteach security issue. The scale shown in Figure 1 and Table 1 takes intoaccount the potential risk of a flaw based on a technical analysis ofthe exact flaw and its type, but not the current threat level.Therefore the rating given to an issue will not change if an exploit orworm is later released for a flaw.
Impact | Description |
---|---|
Critical | This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. |
Important | This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow local or remote users to easily cause a denial of service. |
Moderate | This rating is given to flaws that may be harder or more unlikely to be exploitable but given the right circumstances could still lead to some compromise of the confidentiality, integrity, or availability of resources. |
Low | This rating is given to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences. |
We measure the number of vulnerabilities customers need to deal withusing two metrics: the number of critical vulnerabilities, and thevulnerability workload index.
The vulnerability workload index[5]gives a measure of the number of important vulnerabilities thatsecurity operations staff would need to worry about every day. Thehigher the number, the greater the workload, and the greater thegeneral risk represented by the vulnerabilities. This workload index iscalculated in a similar way to the workload index from NIST[6].
Figure 2 shows the workload index for a full installation ofEnterprise Linux 4 AS. The initial peak during the first month lookssurprising, but is easily explained, as the packages for EnterpriseLinux 4 had a code freeze a few months prior to release. This led to abacklog of security issues that were fixed with updates on the date ofrelease. There is also a peak around August 2006 due mostly to a largenumber of vulnerabilities fixed in an updated version of Firefox, andthe replacement of the Mozilla browser with SeaMonkey[7].
An interesting observation you can make from this graph is that thenumber of weighted vulnerabilities has no particular upward trend;isn’t increasing over time.
During Enterprise Linux 4 installation, the user gets a choice[8]of installing either the default selection of packages, or making acustom selection. Table 2 shows that a default install of EnterpriseLinux 4 AS[9]was only vulnerable to 3 critical flaws. This is because most of thecritical flaws have been in web browsers or plug-ins. Firefox andMozilla/SeaMonkey packages are not installed by default ondistributions intended for server systems.
Client systems (Enterprise Linux WS and Red Hat Desktop) do includeFirefox, Mozilla, and Helixplayer by default, leading to 53 defaultcritical vulnerabilities. A non-default installation of AS, selectingevery available package, would yield a system with the maximum possiblenumber of critical vulnerabilities for the two years, 60.
Severity | Enterprise Linux 4 AS, default install | Enterprise Linux 4 WS, default install | Enterprise Linux 4 AS (all possible packages) |
---|---|---|---|
Critical | 3 | 53 | 60 |
Important | 160 | 189 | 225 |
Moderate | 117 | 161 | 276 |
Low | 82 | 82 | 152 |
Total | 362 | 485 | 713 |
For the purposes of these metrics we consider the worst casescenario, a version of Red Hat Enterprise Linux 4 obtained on the dayof release. During the first two years four Update releases were made(Update 1 in June 2005, Update 2 in October 2005, Update 3 in March2006, Update 4 in August 2006). The Update releases are similar to aservice pack and contain a roll-up of all security advisories to date.So for example, a user who installed Enterprise Linux 4 Update 4 wouldbe vulnerable only to a subset of the issues.
2.1. Critical Flaws
Vulnerabilities rated critical severity are the ones that can posethe most risk to an organisation. By definition, a criticalvulnerability is one that could potentially be exploited remotely andautomatically by a worm. However we also stretch the definition toinclude those flaws that affect web browsers or plug-ins where a useronly needs to visit a malicious (or compromised) web site in order tobe exploited. Since the vast majority of critical severity issuesoccurred due to web browsers or plugins, this is why there is such adifference between the number of critical issues that affects a defaultinstall of Enterprise Linux 4 AS and WS.
To help examine the risk we’ll split the critical vulnerabilitiesinto two categories: Those that require some minimal user interactionto be exploitable (such as if a user visits malicious web page), andthose that require no user interaction at all (and could be exploitedby a worm).
Table 3 itemizes the critical non-browser vulnerabilities for a fullinstall of Enterprise Linux AS, whilst Table 4 summarises for allissues rated critical.
Package | Default Install? | References | Description | “Days of Risk” |
---|---|---|---|---|
sendmail | Yes | CVE-2006-0058 RHSA-2006:0264 | A flaw in the handling of asynchronous signals was discovered inSendmail. A remote attacker may be able to exploit a race condition toexecute arbitrary code as root. | 0 |
mod_auth_pgsql | No | CVE-2005-3656 RHSA-2006:0164 | Several format string flaws were found in the way mod_auth_pgsqllogs information. It may be possible for a remote attacker to executearbitrary code as the ‘apache’ user if mod_auth_pgsql is used for userauthentication. | 0 |
gaim | No | CVE-2005-2103 RHSA-2005:627 | A heap based buffer overflow issue was discovered in the way Gaimprocesses away messages. A remote attacker could send a speciallycrafted away message to a Gaim user logged into AIM or ICQ that couldresult in arbitrary code execution. | 2 |
kopete | Yes | CVE-2005-1852 RHSA-2005:639 | Multiple integer overflow flaws were found in the way Kopeteprocesses Gadu-Gadu messages. A remote attacker could send a speciallycrafted Gadu-Gadu message which would cause Kopete to crash or possiblyexecute arbitrary code | 1 |
gaim | No | CVE-2005-1261 RHSA-2005:429 | A stack based buffer overflow bug was found in the way gaimprocesses a message containing a URL. A remote attacker could send acarefully crafted message resulting in the execution of arbitrary code. | 0 |
Type | Number of vulnerabilities | “Days of Risk” | Fix within one day |
---|---|---|---|
Mozilla products (Firefox, Mozilla, SeaMonkey, Thunderbird) | 44 | 3 | 75% |
Media Player Plugins (HelixPlayer) | 6 | 1.5 | 83% |
Other browser (Lynx, Links, KDE, Qt) | 5 | 1.2 | 80% |
Non-Browser (see table 3) | 5 | 0.6 | 80% |
Total | 60 | 3 | 75% |
From time to time, research reports rate the response times ofvendors with a “days of risk” metric. This is the number of days ittakes for a vendor to produce a patch for a vulnerability after thepatch is first known to the public.
The data in Table 3 shows that fixes for 100% of the critical flawswere available from Red Hat Network within two calendar days of public
disclosure of the vulnerability. 60% of the critical flaws were fixedon the very same day. This fast response time is deliberate and forms an
essential part of reducing customer risk from these critical vulnerabilities.
The “days of risk” metric has it’s limitations and it isn’tparticularly useful for comparing different software vendors againsteach other. Because the software in Enterprise Linux 4 is open sourcewe’re likely not to be the only company shipping each particularapplication. So unlike other commercial companies, Red Hat is not insole control over the date the issue is made public. This is actually agood things and leads to much shorter response times between issuesbeing first reported to being made public. It also means Red Hat can’ttry to artificially reduce our “days of risk” statistics by usingtactics such as holding off disclosure of important issues for a longperiod until a regularly scheduled patch day.
2.2. Riskiest packages
It sometimes seems like we produce a security advisory for somepackages every month; Indeed, a quick scan of the list of securityupdates shows a few packages appear again and again. We thereforeanalysed Enterprise Linux 4 to find out which packages we responsiblefor the most vulnerabilities. We weighted the vulnerabilities[10] to take into account their severity.
Rank (vs last year) | Package | Critical | Important | Moderate | Low |
---|---|---|---|---|---|
1 (was 3) | mozilla/seamonkey | 44 | 21 | 37 | 8 |
2 (-) | firefox | 42 | 30 | 40 | 9 |
3 (was 5) | thunderbird | 22 | 22 | 38 | 4 |
4 (was 1) | kernel | 0 | 83 | 42 | 17 |
5 (was 4) | HelixPlayer | 7 | 6 | 0 | 1 |
6 (-) | gaim | 2 | 6 | 3 | 2 |
7 (-) | cups | 0 | 15 | 2 | 0 |
8 (new entry) | kdelibs | 2 | 3 | 3 | 1 |
9 (-) | kdegraphics | 0 | 13 | 1 | 0 |
10 (was 8 ) | xpdf | 0 | 12 | 1 | 0 |
Table 5 shows the top 10 packages which in total counted for 80% ofall the weighted vulnerabilities. only the kernel and cups are part ofthe default installation of Enterprise Linux 4 AS.
We often do security updates for ethereal/wireshark, and althoughthat package had 75 vulnerabilities through the two years, they wereall moderate or low severity and therefore the overall weighted riskkept it out of the top 10.
- Tip
- Reduce the number of security alerts that apply to your system byremoving packages that you don’t need, particularly those that have theworst security history. When installing a new system, carefullychoosing the right Enterprise Linux variant and package set to matchthe task will cut down on the number of issues that apply to yoursystem.
3. Threats
The first section of this paper analysed the total vulnerabilitiesfound affecting the platform. But to get an estimation of risk we alsoneed to take into account the threat. This section therefore looks atexploits and worms written to exploit those vulnerabilities.
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 trackwhich vulnerabilities are being exploited. For this report we compileda list of the available exploits for the vulnerabilities that affectedthe first two years of Enterprise Linux 4.
We are interested in those exploits that have the potential to causedamage to the confidentiality or integrity and we don’t includeexploits for vulnerabilities that are limited to denial of service(affecting availability). We do however include exploits which arelabeled “proof of concept” (where the published exploit may only causea crash or doesn’t quite work properly but in theory the vulnerabilityif exploited properly could lead to greater consequences). These proofof concept exploits often show techniques that a skilled attacker canturn into a full exploit.
We found exploits for 37 vulnerabilities for the first two years ofvulnerabilities. Just over half of the exploits are for bufferoverflows vulnerabilities where in most cases the Exec-Shieldtechnology should help prevent remote exploitation of thesevulnerabilities due to both the randomisation and enforcement of anon-executable stack.
3.1.1. Kernel exploits
The subset of vulnerabilities affecting the Linux kernel mostly leadto one of two consequences: either a local unprivileged user can causethe machine to crash, or a local user can gain privileges.
We found exploits for seven vulnerabilities that had the potentialto allow an unprivileged user to gain privileges on an un-patchedEnterprise Linux 4 system. Of the seven, one required the target systemto be using bluetooth drivers (CVE-2005-0750), and another wasexploitable only on systems with more than one CPU (CVE-2005-0001).
The remainder (CVE-2006-3626, CVE-2006-2451, CVE-2005-0736,CVE-2004-1235, and CVE-2005-0531) could work on any un-patched system.
Some of those exploits needed code adjustments in order to work against an Enterprise Linux 4 kernel.
3.1.2. Browser exploits
Over a third of the public exploits we found were for flaws in webbrowsers; and all but two targeted the Mozilla suite (Mozilla, Firefox,Thunderbird). These are detailed in Table 6. For each exploit, anyresultant code execution would be limited to being run with the samerights as the user that is running the vulnerable browser. It is bestpractice to never use a web browser or graphical email client as root.
Vulnerabilities | Description |
---|---|
CVE-2005-0399 | An exploit for a flaw where a malicious GIF image could cause anoverflow. This issue is more serious in Thunderbird, where opening amalicious email could trigger this flaw. |
CVE-2006-0295, CVE-2005-2871 | Exploits for flaws where a malicious web page could run arbitrarycode. The public exploit for CVE-2005-2871 was designed for Windows platforms, exploiting this flaw on Linux would require different techniques. |
CVE-2005-1476, CVE-2005-1531, CVE-2005-2264, CVE-2005-1160, CVE-2005-1155, CVE-2005-1157 | Exploits for flaws where a malicious web page could run arbitraryJavaScript, 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 thevictim 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 theexecution of arbitrary code if a victim visits a malicious website. |
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 allowarbitrary commands to be executed if a victim visits a malicious website. |
3.1.3. Other user-complicit exploits
The next class of exploits are those we term ‘user-complicit’, inthat they need some involvement from a user to be exploited. Someexamples of user involvement would be opening a malicious file with avulnerable application, or viewing an instant message from an unknownuser. Table 7 lists the exploits we discovered that require some userinvolvement.
Vulnerabilities | Description |
---|---|
CVE-2005-3243, CVE-2005-2367, CVE-2005-1461, CVE-2005-0699 | Exploits for several vulnerabilities in Ethereal/Wireshark. Inorder to be exploited a victim with privileges (root) would have to berunning Ethereal and monitoring a network onto which an attacker couldinject carefully crafted malicious packets. The protocols affected bythe vulnerabilities (SLIMP3, AFP, SIP, and RADIUS) are unlikely to beallowed through a border firewall, so the ability to exploit this flawremotely is restricted. Additionally, attempts to remotely exploitthese flaws would be caught by Exec-Shield. |
CVE-2005-2710 | An exploit for a format-string vulnerability in HelixPlayer. Anattacker could create a carefully crafted media file that would executearbitrary code when opened by a victim. Since HelixPlayer can beembedded within a web browser, this flaw could be triggered by a victimsimply visiting a malicious web page. Any code execution would howeverbe limited to being run with the same rights as the user that isrunning the vulnerable browser. |
CVE-2005-1261 | An exploit for a flaw in the Gaim instant-messaging client. Forsome instant messaging protocols, an attacker could send a carefullycrafted message which could trigger the flaw and cause code execution.The public exploit is only a proof of concept and causes a crash. Inaddition, attempts to remotely exploit this flaw should be caught byExec-Shield. |
CVE-2005-0156 | An exploit for a flaw in the setuid Perl package. Where perl-setuidis installed, an unprivileged local user could gain root privileges. The exploit as published needs minor changes to work on un-patched Enterprise Linux 4 systems. |
CVE-2006-2656 | An exploit for a flaw in libtiff. If an attacker can force a victimto run the ‘tiffsplit’ executable with a malicious filename they couldcause code to run as that user. This is a low severity flaw as nothingwe ship would run ‘tiffsplit’ with an arbitrary filename. |
CVE-2006-1542 | An exploit for a flaw in Python. This is a low severity issue asthe user would need to be tricked into running python with a very longscript name, an unlikely scenario. |
CVE-2005-1704 | An integer overflow can allow a carefully crafted executable toexecute arbitrary code. This is low severity as you need to convincethe victim to run your malicious binary (and any malicious binary couldperform arbitrary actions anyway). |
3.1.4. Servers and services exploits
Our final class of exploits are those that affect serverapplications and services, in Table 8. These have the potential to bethe most serious threats.
Vulnerabilities | Description |
---|---|
CVE-2005-0022 | An exploit for a buffer overflow in the Exim mail server. A remoteattacker could trigger this vulnerability and execute arbitrary code asthe ‘exim’ unprivileged user. In order to exploit this vulnerabilitythe non-default Exim mail server needs to be installed and SPAauthentication specifically enabled, which is not a usualconfiguration. Attempts to remotely exploit this flaw should also becaught by Exec-Shield. |
CVE-2005-1921, CVE-2005-2498 | Two exploits for flaws in the PHP PEAR XML-RPC code. These exploitsrequire a server to be running a third-party PHP application that exports an XML-RPC interface. A successful exploit will cause arbitraryPHP commands to be executed as the ‘apache’ user. The default SELinuxtargeted policy for Apache will restrict what a successful exploit isable to do. |
CVE-2005-0710, CVE-2005-0709 | Two exploits for flaws in the MySQL server. A remote authenticateduser with privileges to insert or delete from a database table couldexecute 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. |
CVE-2006-4020 | Two exploits for a flaw in the PHP sscanf() function. If a PHPscript was installed that passed data under an attackers control tosscanf() it could result in a buffer overflow. This was low severity asthis is an unlikely scenario, and the default SELinux targeted policyfor Apache would restrict what a successful exploit is able to do. |
- Tip
- The way to reduce your risk from exploits is to make sure yoursystems have all applicable security updates installed. The Red HatNetwork can help keep track of this.
3.2. Worms
Worms take advantage of vulnerabilities in order to compromisesystems, then use the compromised system to seek out other systems toinfect. By our definition, any vulnerability that could be exploited inthis way would be classed as critical. In the first section of thisreport we listed every vulnerability that was rated as criticalseverity and showed that only a subset of those vulnerabilities couldbe actually used by worms. This is because we also class as criticalsome browser vulnerabilities where a victim has to take action (forexample visiting a malicious web page) and therefore are notexploitable by a worm.
Worms affecting Linux platforms have been quite scarce in the lastfew years, and the anti-virus vendors who track malware recorded onlytwo during the two year period of this study:
- Linux/MARE was discovered in November 2005 and was a worm thatspread by exploiting a flaw in PHP-Nuke. PHP-Nuke is not shipped aspart of Red Hat Enterprise Linux.
- Linux/Lupper was discovered in December 2005 and was a worm designed to exploit CVE-2005-1921[11],a flaw in the PHP PEAR XML-RPC server package exploitable through anumber of third party PHP applications. None of the affectedthird-party applications were shipped as part of of Red Hat EnterpriseLinux. Additionally, a PHP update in July 2005 fixed the underlyingvulnerability. Users that had not patched were also protected from thisworm by the default SELinux configuration.
Without common vulnerabilities to allow attackers to remotelyexploit machines, we saw them instead try to focus on exploiting weakconfigurations. During the period of this study we tracked attempts byattackers to exploit machines with brute-force password tools. The
tools simply looked for open SSH services they could connect to, thentried to log in with lots of combinations of possible usernames and
passwords. Restricting access to SSH remotely, moving the SSH daemon toa different port, and making sure all your users have strong
passwords are all useful defenses.
4. Mitigation
Red Hat is continually developing technologies to help reduce therisk of security vulnerabilities, and a number of these wereconsolidated into Red Hat Enterprise Linux 4. The most significanttechnologies were SELinux and Exec-Shield. Exec-Shield is a projectwhich includes support for the No eXecute (NX) memory permission,simulating NX via segment limits, Position Independent Executables(PIE), gcc, and glibc hardening. Table 9 lists the major securitytechnology innovations in Enterprise Linux 3 and 4.
Part of hardening added to glibc included checks which prevent theexploitation of a “double-free”, a particular programming flaw whichcan sometimes be exploitable (it depends a lot on how the vulnerableapplication is written). In 2003 this flaw type led to somehigh-profile exploits of services such as wu-ftpd and CVS pserver.
In August 2004, the first double-free security flaw in Enterprise Linux 4 was announced[12]affecting the MIT Kerberos 5 Key Distribution Center application. ForEnterprise Linux 4 users we were able to downgrade the severity of thisflaw from critical as the glibc hardening totally prevented theexploitation of this double-free flaw.
Feature | Enterprise Linux 3 | Enterprise Linux 4 |
---|---|---|
Digitally signed updates required by default | Yes | Yes |
NX emulation using segment limits by default | Yes, since Sep 2004 | Yes |
Support for Position Independent Executables (PIE) | Yes, since Sep 2004 | Yes |
ASLR for Stack/mmap by default | Yes, since Sep 2004 | Yes |
ASLR for vDSO (if vDSO enabled) | NA | Yes |
Restricted access to kernel memory by default | Yes | |
NX for supported processors/kernels by default | Yes, since Sep 2004 | Yes |
SELinux with targetted policies enabled by default | Yes | |
glibc heap/memory checks by default | Yes | |
Support for FORTIFY_SOURCE, used on selected packages | Yes | |
Support for ELF Data Hardening | Yes | |
CVE compatible | Yes | Yes |
OVAL compatible | Yes, since May 2006 | Yes, since May 2006 |
5. Conclusion
The aim of this report was to look at the security risk to users ofRed Hat Enterprise Linux 4 during the first two years from release.We’ve shown that although on the surface it looks like Red Hat releaseda large number of security advisories, many of them do not apply tousual or default installations, and only a very small subset are a highrisk. We’ve shown:
- A default installation of Enterprise Linux 4 AS was vulnerable to only 3 critical security issues in the whole two years
- A customized installation of Enterprise Linux 4, selecting everypackage, would have been vulnerable to 55 critical browser securityissues, and 5 in non-browser packages in the two years. 75% of thosevulnerabilities had fixes available from the Red Hat Network within oneday of them being known to the public
- We found public exploits for 37 vulnerabilities that could haveaffected a customized full installation; although the majority reliedon user interaction. Attempts to use many of the exploits would becaught by standard Enterprise Linux 4 security innovations
- The most likely successful exploits allowed a local unprivilegeduser to gain root privileges on an un-patched Enterprise Linux 4 machine
- Two worms targeting Linux systems were found during the two years,but both affected third party PHP applications not shipped in Red HatEnterprise Linux 4. In addition, an update to PHP released over threemonths before one of the worms was released protected systems that hadinstalled the third party applications
It would be foolish to draw conclusions about the future state ofsecurity in Red Hat Enterprise Linux 4 solely on the basis of thisanalysis of the past, however what we’ve tried to do is to enumeratethe level of vulnerability and threat and hence overall platform risk.Red Hat treats vulnerabilities in our products and services seriouslyand the policies of the Red Hat Security Response team are specificallydesigned to reduce the risk from security vulnerabilities:
- We place an emphasis on providing the fastest possible, highestquality, turnaround for critical vulnerabilities. We have a globalsecurity response team which can draw on significant development andQuality Engineering resources to get things fixed quickly
- We release updates for critical and important security issues assoon as possible rather than batching them into monthly or quarterlyupdates
- We give transparency in our 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[13]from the Red Hat Security Response Team and updated regularly. We alsoprovide other tools and data that can help security measurementincluding CVE mappings on all our advisories and OVAL definitions.
6. Further Reading
- What’s new in security for Red Hat Enterprise Linux 4
- Vulnerability Types for Enterprise Linux 4
- Security Features in Red Hat Enterprise Linux and Fedora Core
- SELinux: A New Approach to Secure Systems
- Red Hat Enterprise Linux 4 Security Guide
- Statistics and data from the Security Response Team
7. About the author
Mark Cox is Director of the Red Hat Security Response Team. Over thelast 12 years, Mark has developed software and worked on the securityteams of some of the most popular open source projects includingApache, mod_ssl, and OpenSSL. Mark is a founding member of the ApacheSoftware Foundation and the OpenSSL project, and a board member of theMitre Common Vulnerabilities and Exposure project. In his spare time hefinds geocaches [14] with his family in Scotland.
[2] http://rhn.redhat.com/errata/rhel4as-errata.html
[3] Get notified of new security issues
[4] http://www.redhat.com/security/updates/classification/
[5] For a given date, Vulnerability workload = ((number of critical andimportant severity vulnerabilities published within the last month) +(number of moderate severity vulnerabilities published within the lastmonth/5) + (number of low severity vulnerabilities published within thelast month/20)) / (days in the month)
[6] http://nvd.nist.gov/nvd.cfm?workloadindex
[7] http://rhn.redhat.com/errata/RHSA-2006-0609.html
[8] http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/x8664-multi-install-guide/s1-pkgselection.html
[9] There are four variants of Red Hat Enterprise Linux 4; two targeted atserver solutions with Enterprise Linux AS and ES, and two targeted atclient solutions with Enterprise Linux WS and Red Hat Desktop. Thepackage set available in Enterprise Linux WS and Red Hat Desktop is asubset of that available in Enterprise Linux AS.
[10] To rank the riskiest packages we use a weighting of “Critical + Important/5
+ Moderate/25 + Low/100″
[12] http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2004-002-dblfree.txt
'한신대학교 정조교양대학 교직과' 카테고리의 다른 글
메탈리카 S&M Master of puppets (0) | 2015.06.22 |
---|---|
中國化學會 (0) | 2015.06.17 |
강예빈 (0) | 2015.05.31 |
서태지 - 울트라맨이야 (0) | 2015.05.29 |
로보트태권브이 The UN Refugee Agency (0) | 2015.05.29 |