Outside-in Vulnerability Assessment for Secure Software Development

Posted on by
Reply

Outside-in vulnerability assessment for secure software development is a process for identifying and eliminating some of the most dangerous and potentially exploitable weaknesses in your existing products and projects.

Some well-known secure software development methodologies have their security practices grouped into phases, from training to response. However, you may have your main product already within the response phase, whereas its development was not done practicing secure software development methodology. This is often true for open source software vendors where training upstream developers for development of its own software is not always viable. This is where outside-in vulnerability assessment can help.

Even if you are not an open source software vendor and have in-house development of your software, outside-in vulnerability assessment can complement any approach your team may be practicing for software development. Sometimes it’s not possible to withdraw your product from the market, educate your developers, and start the development of your product from the scratch, nor can you do this for the next version of your product. You need to respond to whatever problem is identified in your product, immediately.

Red Hat has a team dedicated to vulnerability assessment, the Red Hat Security Response Team, which uses CVE identifiers and CVSS scores for identifying, coordinating, and prioritizing the correction of the vulnerabilities identified and reported in its products. The Red Hat Security Response Team also uses a common taxonomy for classifying, quantifying, and ranking the weaknesses that resulted in these vulnerabilities, which can also be understood by developers, and preferably also supported by security assessment tools. The language chosen by the Red Hat Product Security Team is the Common Weakness Enumeration or CWE.

In this first phase, we assigned CWE identifiers, chains, and composites, to past, current, and future Red Hat vulnerabilities with a CVSS v2 score higher than or equal to 7. Periodically, after classifying, quantifying, and ranking these weaknesses, we plan to direct our efforts into dealing with these weaknesses in our products as part of our assessment services, knowledge repositories, software development practices, and education offerings.
This approach is different from what some companies practice for software development, where CWE identifiers are used to track the issues that they have addressed during development of their software. The outside-in vulnerability assessment streamlines the efforts directly on recurring weaknesses resulting from programming practices that, consequently, tend to recur often.

In future posts, I will go through the Red Hat engagement for CWE compatibility, how CWE identifiers are assigned to Red Hat vulnerabilities, and the reasons behind the decisions for the elements in the CWE subset chosen for the outside-in vulnerability assessment.

Battling open resolvers

Posted on by
Reply

A recent blog by ISC discussed Is Your Open DNS Resolver Part of a Criminal Conspiracy?

The problem is that open recursive DNS servers can be used by attackers to attack victims as part of distributed denial of service (DDOS) attacks. This type of attack is generally known as a DNS amplification attack. Due to the nature of the DNS protocol, a very small request can be sent as a UDP packet, and since UDP is not a stateful protocol, the sender information can be faked. The open DNS resolver will then “amplify” the request, allowing an attacker to use very little of their own bandwith to consume a great deal of the victim’s bandwith.

This issue has been known for several years. In 2007, with BIND 9.4.1-P1, the default behaviour of BIND was changed to help prevent resolvers being left open by mistake. Prior to version 9.4.1-P1, the default behavior of BIND was to act as an open recursive DNS server. Version 9.4.1-P1 of BIND no longer allowed the server to act as an open resolver by default; the administrator had to explicitly enable this feature.

This change is described in detail here, https://kb.isc.org/article/AA-00269/0/What-has-changed-in-the-behavior-of-allow-recursion-and-allow-query-cache.html , specifically: ‘If not explicitly set, the ACLs for “allow-query-cache” and “allow-recursion” were set to “localnets; localhost;”.’

Red Hat Enterprise Linux 5 ships an older (pre 9.4.1-P1) version of BIND and therefore allows open recursion. However, by default in Red Hat Enterprise Linux 5, BIND is configured to only listen to the localhost interface (via the listen-on parameter).

It is possible that administrators may, in the course of configuring an authoritative server, change the listening interface and neglect to secure the recursion settings. We are therefore looking at improving the documentation in a default configuration file to better explain the risks of making changes without fully understanding the implications. You can view the progress of this at https://bugzilla.redhat.com/show_bug.cgi?id=952311 . If you use Red Hat Enterprise Linux 5 and have configured BIND, you should check to make sure you have disabled recursion.

Red Hat Enterprise Linux 6 (and above) ships with a version of BIND that is newer than 9.4.1-P1 and does not act as a recursive DNS server unless explicitly told to do so.

Anatomy of a Red Hat Security Advisory

Posted on by
Reply

Red Hat Security Advisories (RHSA) document the security flaws being fixed in Red Hat products. They include:

  • The affected products the advisory applies to.
  • The security rating of the update (low, moderate, important, critical).
  • A brief description of the flaws being fixed.
  • How an attacker could exploit the issues, such as whether they need privileges or not.
  • Any manual action that may be required, such as restarting applications that use an affected library, or configuration file changes.
  • In the case of ZIP updates for certain JBoss products, information on where to find the update in the Red Hat Customer Portal.

The advisories also link to a page containing the GPG keys used to sign the packages and instructions for verification, and the key used to communicate securely with the Red Hat Security Response Team and to sign the advisories that are mailed to the enterprise-watch-list, rhsa-announce, rhev-watch-list, and jboss-watch-list mailing lists.

Where to find the advisories

The content of RHSAs can be viewed with the pup tool on Red Hat Enterprise Linux 5 and the PackageKit tool on Red Hat Enterprise Linux 6. These tools only display advisories that affect the given system, for example, an advisory for package1 will not be displayed if package1 is not installed on your system. The yum tool will not display the content of the advisory, just the affected package name. Updates will not be displayed by these tools or be able to be installed on systems that are not registered to the Red Hat Network or a Red Hat Network Satellite server. E-mail notification of new updates is available from the Red Hat Network.

Security advisories for all packages and all products can be viewed on https://rhn.redhat.com/errata/ or via the enterprise-watch-list, rhsa-announce, rhev-watch-list, and jboss-watch-list mailing lists. Note that non-security advisories are not mailed to these lists.

Users of JBoss products distributed as ZIP files from the Red Hat Customer Portal are encouraged to subscribe to the jboss-watch-list mailing list. E-mail notification of new updates can also be configured in the Customer Portal.

Advisory content

Using RHSA-2013:0608 as an example, the advisory’s synopsis provides the overall security impact and the name of the affected package:

Important: kvm security update

The Red Hat Security Response Team rates the impact of security issues in Red Hat products using a four-point scale (low, moderate, important, and critical). The four-point scale tells you how serious Red Hat considers an issue to be, helping you judge the severity and determine what the most important updates are. The scale takes into account the potential risk based on a technical analysis of the exact flaw and its type, but not the current threat level; a given rating will likely not change if an exploit or worm is later released for a flaw, or if one is available before the release of a fix.

The package name is the actual package name that you would find on your system, for example, “yum install kvm”, not the project or product name, Kernel-based Virtual Machine (KVM).

The heading information that follows notes when the advisory was released (the “Issued on” date); if the advisory was modified after the initial release (the “Last updated on” date); all of the Red Hat Network channels the affected package resides in; and the Common Vulnerabilities and Exposures (CVE) names that are fixed by the advisory.

CVE names are listed after security descriptions, rather than Red Hat Bugzilla numbers which are found after bug fix and enhancement descriptions. Refer to the Red Hat and CVE compatibility page for more information about CVE.

Updated kvm packages that fix one security issue are now available for Red Hat Enterprise Linux 5.

The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link in the References section.

The next two paragraphs provide:

  • The affected package name (kvm).
  • The product the update applies to (Red Hat Enterprise Linux 5).
  • How many security issues are being fixed, and whether there are also bug fixes and enhancements with the update.
  • The advisory’s overall impact, which is the impact of the highest rating flaw. An advisory may fix one impact important issue and several low impact issues, but the overall impact will be important.
  • A pointer to the Common Vulnerability Scoring System (CVSS) base scores, which provide a more detailed rating than the four-point scale. Refer to https://access.redhat.com/security/updates/classification/ for more information about CVSS.

The package name and impact allow you to tell at a glance if the advisory is something you need to deal with immediately.

This section is important for JBoss updates shipped via ZIP files in the Customer Portal as it will detail the exact version the update is for. An example from RHSA-2013:0569:

An update for the JBoss Web Services component in JBoss Enterprise SOA Platform 4.3 CP05 and JBoss Enterprise Portal Platform 4.3 CP07 which fixes one security issue is now available from the Red Hat Customer Portal.

The next paragraph typically describes what the package (or product) provides and does:

KVM (Kernel-based Virtual Machine) is a full virtualization solution for Linux on AMD64 and Intel 64 systems. KVM is a Linux kernel module built for the standard Red Hat Enterprise Linux kernel.

Descriptions for the flaws the update fixes follow:

A flaw was found in the way QEMU-KVM emulated the e1000 network interface card when the host was configured to accept jumbo network frames, and a guest using the e1000 emulated driver was not. A remote attacker could use this flaw to crash the guest or, potentially, execute arbitrary code with root privileges in the guest. (CVE-2012-6075)

In this case, the description provides:

  • Where the flaw is.
  • The configuration required to be affected by the flaw. Configuration details are not always provided, such as when the default configuration is affected, or when configuration changes do not change whether a flaw affects your system or not.

The description will note if the issue only affects certain architectures, such as an issue that only affects 64-bit systems, but not 32-bit systems.

  • Who can trigger the issue, such as whether the issue can be triggered remotely over a network, or if you must be on the local system.
  • The result of successfully exploiting the issue, such as causing a denial of service, obtaining information you would otherwise not be able to access without the flaw, or executing arbitrary code with the privileges of the vulnerable process.
  • The CVE number assigned to the issue.

For kernel errata, individual impacts are listed after each description. An example from RHSA-2013:0695:

… A local, unprivileged user could use this flaw to escalate their privileges. (CVE-2013-0871, Important)

Individual impacts for issues in non-kernel errata can be found in the Red Hat CVE Database. For example, the top of the page on https://access.redhat.com/security/cve/CVE-2012-6075 notes:

CVE-2012-6075
Impact: Important

JBoss errata typically contain a Warning after the descriptions, noting if anything should be backed-up before applying the update.

The final paragraph usually describes if the issues were fixed by backporting patches, or if the package was upgraded to a new upstream version. It will also note any manual actions required to apply the update, if any:

All users of kvm are advised to upgrade to these updated packages, which contain backported patches to correct this issue. Note that the procedure in the Solution section must be performed before this update will take effect.

We use the term backporting to describe when we take a fix for a security flaw out of the most recent version of an upstream software package and apply that fix to an older version of the package we distribute. With backporting, customers need to be aware that just looking at the version number of a package will not tell them if they are vulnerable to an issue or not. Refer to the Backporting Security Fixes page for further information.

It is important to read the last paragraph, even though it often looks like boilerplate, as it may contain important information about how to apply the update.

The Solution section contains a link to the Red Hat Knowledgebase article that describes how to install the update. This section may contain manual steps needed to apply the update.

The “Bugs fixed (see bugzilla for more information)” section contains links to Red Hat Bugzilla where more detailed information about the fixed issues can sometimes be found.

The References section links to entries in the Red Hat CVE Database. Here you can find the CVSS scores for the issues, other products the issues have been fixed in, if any, and any statements about the issues (for example, a future update may correct the issue in a different product).

A link is also provided to the page that explains the four-point severity rating scale and in-depth information about CVSS scoring.

The References field sometimes links to upstream advisories, or other sources providing additional information about the issues.

End of life notifications

End of life notifications are shipped as security advisories. Such notifications could be for packages, for example:

https://rhn.redhat.com/errata/RHSA-2013-0666.html

Or for products, for example:

https://rhn.redhat.com/errata/RHSA-2012-1015.html

Other sources of information

The Red Hat CVE Database provides information about CVE named issues, including CVSS scores, errata that have fixed the issue (if any), and official statements about whether an issue affects or does not affect Red Hat products.

If you have a CVE name and cannot find an errata for the issue, you can use the database to check for official statements. For example, the “Statement” section of https://access.redhat.com/security/cve/CVE-2013-0151 explains that CVE-2013-0151 does not affect Red Hat products. The “Statement” section of https://access.redhat.com/security/cve/CVE-2013-0157 explains the issue has already been fixed in Red Hat Enterprise Linux 6, and that a future update may fix it in Red Hat Enterprise Linux 5.

The “Statement” section contains official statements from the Red Hat Security Response Team. The “Details” section contains text from The MITRE Corporation. It is not uncommon to find “** RESERVED **” text in this section until MITRE’s database has been updated with a description. Note that the text from MITRE is not specific to Red Hat products.

Knowledgebase articles are created for critical impact issues, as well as issues customers would consider critical even if we did not rate them as impact critical. The articles sometimes contain mitigation information that can be used until updates have been released and applied. Searching the Customer Portal based on a CVE name will find related Knowledgebase articles if they exist.

Contact secalert@redhat.com if you are unsure about how a known vulnerability affects a Red Hat product or service.