Twitter is the latest major Internet company to establish a bug bounty program, and has put no upper limit on the bounty that a researcher can earn for reporting a vulnerability. The company announced on Wednesday that it will operate its bounty program through the HackerOne platform, a bug bounty system that enables vendors to […]
Tag Archives: Vulnerabilities
Firefox 32 Debuts With Public-Key Pinning, Several Security Fixes
Mozilla has released Firefox 32, the latest version of its browser, which now supports public-key pinning and also includes fixes for several critical security vulnerabilities. The move to support public-key pinning is an important one for Firefox, as it helps protect users against man-in-the-middle attacks that rely on forged certificates. The feature binds a set […]
Gary McGraw on the IEEE Center for Secure Design
Dennis Fisher talks with Gary McGraw of Cigital about the IEEE’s new Center for Secure Design program, the difficulty of defeating large classes of bugs and the collaborative effort it will take to solve the software security problem.
Is your software fixed?
A common query seen at Red Hat is “our auditor says our Red Hat machines are vulnerable to CVE-2015-1234, is this true?†or “Why hasn’t Red Hat updated software package foo to version 1.2.3?†In other words, our customers (and their auditors) are not sure whether or not we have fixed a security vulnerability, or if a given package is up to date with respect to security issues. In an effort to help our security-conscious customers, Red Hat make this information available in an easy to consume format.
What’s the deal with CVEs?
Red Hat is committed to the CVE process. To quote our CVE compatibility page:
We believe that giving our users accurate and complete information about security issues is extremely important. By including CVE names when we discuss security issues in our services and products, we can help users cross-reference vulnerabilities so they spend less time investigating and categorizing security events.
Red Hat has a representative on the CVE Editorial Board and declared CVE compatibility in April 2002.
To put it simply: if it’s a security issue and we fix it in an RHSA it gets a CVE. In fact we usually assign CVEs as soon as we determine a security issue exists (additional information on determining what constitutes a security issue can be found on our blog.).
How to tell if you software is fixed?
A CVE can be queried at our public CVE page. Details concerning the vulnerability, the CVSS v2 metrics, and security errata are easily accessible from here.
To verify you system is secure, simply check which version of the package you have installed and if the NVR of your installed package is equal to or higher than the NVR of the package in the RHSA then you’re safe.
What’s an NVR?
The NVR is the Name-Version-Release of the package. The Heartbleed RHSA lists packages such as: openssl-1.0.1e-16.el6_5.7.x86_64.rpm. So from this we see a package name of “openssl†(a hyphen), a version of 1.0.1e (a hyphen) and the release is 16.el6_5.7. Assuming you are running RHEL 6, x86_64, if you have openssl version 1.0.1e release 16.el6_5.7 or later you’re protected from the Heartbleed issue.
Please note, there is an additional field called “epoch”, this field actually supersedes the version number (and release), most packages do not have an epoch number, however a larger epoch number means that a package can override a package with a lower epoch. This can be useful, for example, if you need a custom modified version of a package that also exists in RPM repos you are already using. By assigning an epoch number to your package RPM you can override the same version package RPMs from another repo even if they have a higher version number. So be aware, using packages that have the same name and a higher epoch number you will not get security updates unless you specifically create new RPM’s with the epoch number and the security update.
But what if there is no CVE page?
As part of our process the CVE pages are automatically created if public entries exist in Bugzilla. CVE information may not be available if the details of the vulnerability have not been released or the issue is still embargoed. We do encourage responsible handling of vulnerabilities and sometimes delay CVE information from being made public.
Also, CVE information will not be created if the software we shipped wasn’t vulnerable.
How to tell if your system is vulnerable?
If you have a specific CVE or set of CVEs that you are worried about you can use the yum command to see if your system is vulnerable. Start by installing yum-plugin-security:
sudo yum install yum-plugin-security
Then query the CVE you are interested in, for example on a RHEL 7 system without the OpenSSL update:
[root@localhost ~]# yum updateinfo info --cve CVE-2014-0224
===============================================
Important: openssl security update
===============================================
Update ID : RHSA-2014:0679
Release :
Type : security
Status : final
Issued : 2014-06-10 00:00:00
Bugs : 1087195 - CVE-2010-5298 openssl: freelist misuse causing
a possible use-after-free
: 1093837 - CVE-2014-0198 openssl: SSL_MODE_RELEASE_BUFFERS NULL
pointer dereference in do_ssl3_write()
: 1103586 - CVE-2014-0224 openssl: SSL/TLS MITM vulnerability
: 1103593 - CVE-2014-0221 openssl: DoS when sending invalid DTLS
handshake
: 1103598 - CVE-2014-0195 openssl: Buffer overflow via DTLS
invalid fragment
: 1103600 - CVE-2014-3470 openssl: client-side denial of service
when using anonymous ECDH
CVEs : CVE-2014-0224
: CVE-2014-0221
: CVE-2014-0198
: CVE-2014-0195
: CVE-2010-5298
: CVE-2014-3470
Description : OpenSSL is a toolkit that implements the Secure
Sockets Layer
If your system is up to date or the CVE doesn’t affect the platform you’re on then no information will be returned.
Conclusion
Red Hat Product Security makes available as much information as we can regarding vulnerabilities affecting our customers. This information is available on our customer portal as well as within the software repositories. As you can see it is both easy and quick to determine if your system is up to date on security patches with the provided information and tools.
The following checklist can be used to check if systems or packages are affected by specific security issues:
1) Check if the issue you’re concerned about has a CVE and check the Red Hat CVE page:
https://access.redhat.com/security/cve/CVE-2014-0224
2) Check to see if your system is up to date for that issue:
sudo yum install yum-plugin-security yum updateinfo info --cve CVE-2014-0224
3) Alternatively you can check the package NVR in the RHSA errata listed in the CVE page (in #1) and compare it to the packages on your system to see if they are the same or greater.
4) If you still have questions please contact Red Hat Support!
Watering Hole Attack Targets Automotive, Aerospace Industries
A new watering hole attack is targeting the aerospace, automotive and manufacturing industries with a new reconnaissance malware tool called “Scanbox.”
Fedora Security Team
Vulnerabilities in software happen. When they get fixed it’s up to the packager to make those fixes available to the systems using the software. Duplicating much of the response efforts that Red Hat Product Security performs for Red Hat products, the Fedora Security Team (FST) has recently been created to assist packagers get vulnerability fixes downstream in a timely manner.
At the beginning of July, there were over 500 vulnerability tickets open* against Fedora and EPEL. Many of these vulnerabilities already had patches or releases available to remedy the problems but not all. The Team has already found several examples of upstream not knowing that the vulnerability exists and was able to fix the issue quickly. This is one of the reasons having a dedicated team to work these issues is so important.
In the few short weeks since the Team was created, we’ve already closed 14 vulnerability tickets and are working another 150. We hope to be able to work in a more real-time environment once the backlog decreases. Staying in front of the vulnerabilities will not be easy, however. During the week of August 3rd, 27 new tickets were opened for packages in Fedora and EPEL. While we haven’t figured out a way to get ahead of the problem, we are trying to deal with the aftermath and get fixes pushed to the users as quickly as possible.
Additional information on the mission and the Team can be found on our wiki page. If you’d like to get involved please join us for one of our meetings and subscribe to our listserv.
* A separate vulnerability ticket is sometimes opened for different versions of Fedora and EPEL resulting in multiple tickets for a single vulnerability. This makes informing the packager easier but also inflates the numbers significantly.
Towards efficient security code audits
Conducting a code review is often a daunting task, especially when the goal is to find security flaws. They can, and usually are, hidden in all parts and levels of the application – from the lowest level coding errors, through unsafe coding constructs, misuse of APIs, to the overall architecture of the application. Size and quality of the codebase, quality of (hopefully) existing documentation and time restrictions are the main complications of the review. It is therefore useful to have a plan beforehand: know what to look for, how to find the flaws efficiently and how to prioritize.
Code review should start by collecting and reviewing existing documentation about the application. The goal is to get a decent overall picture about the application – what is the expected functionality, what requirements can be possibly expected from the security standpoint, where are the trust boundaries. Not all flaws with security implications are relevant in all contexts, e.g. effective denial of service against server certainly has security implications, whereas coding error in command line application which causes excessive CPU load will probably have low impact. At the end of this phase it should be clear what are the security requirements and which flaws could have the highest impact.
Armed with this knowledge the next step is to define the scope for audit. It is generally always the case that conducting a thorough review would require much more resources than are available, so defining what parts will be audited and which vulnerabilities will be searched for increases efficiency of the audit. It is however necessary to state all the assumptions made explicitly in the report – this makes it possible for others to review them or revisit them in the future in next audits.
In general there are two approaches to conducting a code review – for the lack of better terminology we shall call them bottom up and top down. Of course, real audits always combine techniques from both, so this classification is merely useful when we want to put them in a context.
The top down approach starts with the overall picture of the application and security requirements and drills down towards lower levels of abstraction. We often start by identifying components of application, their relationships and mapping the flow of data. Drilling further down, we can choose to inspect potentially sensitive interfaces which components provide, how data is handled at rest and in motion, how access to sensitive parts of application are restricted etc. From this point audit is quickly becoming very targeted – since we have a good picture of which components, interfaces and channels might be vulnerable to which classes of attacks, we can focus our search and ignore the other parts. Sometimes this will bring us down to the level of line-by-line code inspection, but this is fine – it usually means that architecturally some part of security of application depends on correctness of the code in question.
Top down approach is invaluable, as it is possible to find flaws in overall architecture that would otherwise go unnoticed. However, it is also very demanding – it requires a broad knowledge of all classes of weaknesses, threat models and ability to switch between abstraction levels quickly. Cost of such audit can be reduced by reviewing the application very early in the design phase – unfortunately most of the times this is not possible due to development model chosen or phase in which audit was requested. Another way how to reduce the effort is to invest effort into documentation and reusing it in the future audits.
In the bottom up approach we usually look for indications of vulnerabilities in the code itself and investigate whether they can possibly lead to exploitation. These indications may include outright dangerous code, misuse of APIs, dangerous coding constructs and bad practices to poor code quality – all of these may indicate presence of weakness in the code. Search is usually automated, as there is abundance of tools to simplify this task including static analyzers, code quality metric tools and the most versatile one: grep. All of these reduce the cost of finding a potentially weak spots and so the cost lies in separating wheat from chaff. Bane of this appoach is receiver operating characteristic curve – it is difficult to substantially improve it, so we are usually left with the tradeoffs between false positives and false negatives.
Advantages of bottom up approach are relatively low requirements on resources and reusability. This means it is often easy and desirable to run such analyses as early and as often as possible. It is also much less depends on the skill of the reviewer, since the patterns can be collected to create a knowledgebase, aided with freely available resources on internet. It is a good idea to create checklists to make sure all common types of weaknesses are audited for and make this kind of review more scalable. On the other hand, biggest disadvantage is that certain classes of weaknesses can never be found with this approach – these usually include architectural flaws which lead to vulnerabilities with biggest impact.
The last step in any audit is writing a report. Even though this is usually perceived as the least productive time spent, it is an important one. A good report can enable other interested parties to further scrutinize weak points, provides necessary information to make a potentially hard decisions and is a good way to share and reuse knowledge that might otherwise stay private.
Frequently Asked Questions about the Shellshock Bash flaws
The recent few days have been hectic for everyone who works in the Linux/Unix world. Bash security flaws have rocked the globe leaving people confused, worried, or just frustrated. Now that the storm is over and patches are available for most operating systems, here are the answers to some of the common questions we’ve been asked:
Why are there four CVE assignments?
The original flaw in Bash was assigned CVE-2014-6271. Shortly after that issue went public a researcher found a similar flaw that wasn’t blocked by the first fix and this was assigned CVE-2014-7169. Later, Red Hat Product Security researcher Florian Weimer found additional problems and they were assigned CVE-2014-7186 and CVE-2014-7187. It’s possible that other issues will be found in the future and assigned a CVE designator even if they are blocked by the existing patches.
Is CVE-2014-7169 the same severity as the original flaw?
Our research, and that of others, shows that it would not have been possible to exploit the CVE-2014-7169 flaw remotely in the same way that it was for the previous flaw. So, even though there were security consequences of the CVE-2014-7169 flaw, it was certainly not as severe as the original flaw.
Why did Red Hat delay in providing a patch for CVE-2014-7169?
When a second issue with Bash was found a few minutes after the first one went public, we knew there was something wrong. We could have followed a duct-tape approach and issued patches to our customers quickly or we could have done this correctly. Applying multiple security updates is extremely difficult!
When CVE-2014-7169 went public, there was a lot of visible confusion around how to address this issue. This was fueled by the media and by the fact that exploits were immediately available on the Internet.
Red Hat carefully analyzed the root cause of the issue and wrote and tested patches. We posted these patches to the community for review and allowing everyone to freely use them if they wanted to. Doing things correctly takes time!
Why is Red Hat using a different patch then others?
Our patch addresses the CVE-2014-7169 issue in a much better way than the upstream patch, we wanted to make sure the issue was properly dealt with.
I have deployed web application filters to block CVE-2014-6271. Are these filters also effective against the subsequent flaws?
If configured properly and applied to all relevant places, the “() {” signature will work against these additional flaws.
Does SELinux help protect against this flaw?
SELinux can help reduce the impact of some of the exploits for this issue. SELinux guru Dan Walsh has written about this in depth in his blog.
Are you aware of any new ways to exploit this issue?
Within a few hours of the first issue being public (CVE-2014-6271), various exploits were seen live, they attacked the services we identified at risk in our first post: from dhclient, CGI serving web servers, sshd+ForceCommand configuration, git repositories. We did not see any exploits which were targeted at servers which had the first issue fixed, but were affected by the second issue. We are currently not aware of any exploits which target bash packages which have both CVE patches applied.
Why wasn’t this flaw noticed sooner?
The flaws in Bash were in a quite obscure feature that was rarely used; it is not surprising that this code had not been given much attention. When the first flaw was discovered it was reported responsibly to vendors who worked over a period of under 2 weeks to address the issue.
Did you have an outage?
Our security blog article was widely regarded as the definitive source of information about the flaw, being referenced in news articles, on Wikipedia, and from organizations such as US-CERT. This caused more demand than we expected so we did have some periods on Thursday where the blog was unavailable. Our customer portal also had some problems keeping up with demand at times. Many of the issues we saw have already been corrected.
Is my lightbulb really affected by these flaws?
Only if your lightbulb runs Bash! Lots of press have latched onto the fact that this flaw could affect the Internet Of Things, allowing attackers to take control of your systems via home appliances. In reality, embedded devices rarely use Bash, going for more lightweight solutions such as BusyBox, which includes the ash shell that was not vulnerable to these issues. So while it’s certainly plausible that some devices may be affected by this flaw, it won’t be very common.