Is Linux SSL/TLS Flaw an NSA Backdoor?

A code audit conducted by Red Hat in February uncovered a critical bug in the SSL/TLS security implementation in Linux (Secure Socket Layer/Transport Layer Security). This followed a similar bug found in Apple products last month.

The flaw allows an attacker to gain access the SSL/TLS stack which encrypts data being transferred between two points on a network (like the Internet) through a fraudulent security certificate. SSL is used for everything from securing your banking transactions to protecting your email and chats.

The bug effects not only Red Hat but most every Linux distribution and has been in place for a decade or more. The amount of software which uses this protocol and may have to be updated could be staggering.

TLS is an updated form of SSL and uses a protocol developed by the IETF (Internet Engineering Task Force), which was developed in 1999 and updated in 2008 and 2011. (Interestingly, a Snowden leaked documents from 2012 show the NSA had recently added Apple users to it's list of compromised systems.)

Chrome and Firefox users are safe from this bug as they use OpenSSL, which is not affected by this vulnerability.

How could such a gaping hole go so long without being discovered in Open Source software? Don't 'many eyes make all bugs shallow?'

According this article in PCWorld, to David Walser, a security manager for Mageia Linux, explained,

“The code is extremely complicated. Even though the code is freely available for review, only a select group of people would be qualified to accurately analyze and understand the whole system well enough to catch such a subtle bug. It’s also not the type of vulnerability that can be found by automated analysis tools, requiring manual scrutiny instead."

In September of 2013, Linus Torvalds caused a stir in the Linux community when he indicated, through a nod of the head, that the NSA had requested a back door into Linux systems.

Following news of the hint, Linus is reported to have said he was joking. Was this retraction due to the Linux community not getting the joke or was it due to legal advice? Linus is not known for his sense of humor. Rather, he is known for being honestly blunt, sometimes a bit too blunt.

The question has hung in the air ever since: Is there a backdoor in Linux?  And is this SSL/TLS vulnerablity an NSA backdoor?

The FBI has been obsessed with breaking encryption for more than a decade. Leaked documents by Edward Snowden have shown the NSA went to great lengths to access encrypted data. From pressuring companies to install government accessible back doors or provide encryption keys or stealing keys from those who did not cooperate. According to the NY Times:

"The N.S.A. hacked into target computers to snare messages before they were encrypted. In some cases, companies say they were coerced by the government into handing over their master encryption keys or building in a back door. And the agency used its influence as the world’s most experienced code maker to covertly introduce weaknesses into the encryption standards followed by hardware and software developers around the world."

There was also a purported back-door in the OpenBSD operating system, which was disclosed on a mailing list in December of 2010. The writer stated that his non-disclosure agreement had recently expired and he wanted everyone to know that security holes had been intentionally placed in the system:

"My NDA with the FBI has recently expired, and I wanted to make you aware of the fact that the FBI implemented a number of backdoors and side channel key leaking mechanisms into the OCF, for the express purpose of monitoring the site to site VPN encryption system implemented by EOUSA, the parent organization to the FBI."

No known back door was found in FreeBSD when this was reported. But the time frame and data targeted fits with the decade old flaw recently disclosed in Linux systems.

We don't know if this huge security flaw was intentionally placed in Linux systems or it was a coding error. No one can say how it got there. But no one can dispute that it has existed unnoticed for a very long time.

A patch for the bug has been rolled out and is available for most Linux distributions. Update your system now.

Thank you to Red Hat for finding and disclosing this bug. This shows without a doubt that open code does not guarantee security. And automated tools for finding flaws is no substitute for trained eyes.

The days of "Many eyes make all bugs shallow" may be true for actual bugs, but what of intentional vulnerabilities which have been carefully obfuscated or a small but profound mistake in millions of lines of code? Perhaps the adage needs to be changed to reflect the level of complexity in today's code: "Qualified eyes make all bugs shallow."

freedigitalphotos.net/twobee

Using Apport to Report Bugs in Ubuntu

Open Source projects depend on an active community of users and developers to contribute their time and skills to improve individual projects and the open source ecosystem in general. All users can contribute to Ubuntu by using Apport to report bugs for fixing.

Ubuntu uses Launchpad for bug tracking and Apport for bug reports. It is designed to be easy for the user as it collects info about the OS, running processes and hardware during crashes. You don't need to be able to reproduce the bug to provide useful information for the developers.

Generally Apport supports two types of bug reports:

1) Launched when you experience a crash. Automatically opens apport and walks you through the reporting process.

2) Initiated by the user when bug is noticed during use of a program but does not cause a crash, for example an application option that does not work as expected or a problem with the user interface.

When a crash occurs Apport creates a persistent and detailed crash report in /var/crash which can be used to determine the problem, even for bugs which are difficult to reproduce. This report contains detailed information about system state and installed software. Apport uses package hooks to collect additional information from log and configuration files.

Sometimes crashes can be hard to attribute to a specific program or service so Apport uses the apport-symptoms package symptom based bug reporting. The UI guides the user through selection of symptoms and uses question and answer scripts to locate the offending package and determine what data to collect.

Bugs which affect large number of users may have already be reported many times and this can cause unnecessary work for developers and users. Apport uses 'Bug Patterns' to recognize specific recurring errors and instead of filing a new report, takes the user to the Launchpad bug page where they can review previous reports and determine if this a new or known bug.

Bugs in X drivers, sound and the kernel should always open a new bug report to be sure your hardware is included in any fix.

Following a program crash, a message will appear offering to help you report the problem. If you were entering confidential information when the crash occurred you should click 'Cancel'.

Most of the time crashes occur when you are performing routine tasks and these should be reported. Click 'Report Problem...' to begin collecting information about what your computer was doing when the crash occurred.

Apport will ask to 'Send problem report to the developers?' Click 'Content of the report' to view the data apport has collected or you can open the plain text document in /var/crash. If you would like to file the report later, you can navigate to this report and double click on it. Apport-gtk will open allowing you to file the bug report.

Click 'Send Report' to upload the report to Launchpad's bug tracking system. Your browser will launch and you will be directed to Launchpad to login or create an account. You are then taken to the packages' bug filing page.

Look over the list of 'hot bugs' and see if your bug is listed there. If the problem has been previously reported, click on 'Mark as Duplicate'. If it is a new bug, click 'Report Bug'.

Briefly describe the the problem and what caused it, if known. Launchpad will search for similar bug reports. If none are found to match your problem, you will be asked for further information. Be sure to include what you were trying to do, what actually occurred and the steps to reproduce the problem, if known.

If the bug is a security risk, click the box 'This bug is a security vulnerability.'

Click 'Extra Options' to add tags to this report, attach files such as logs or screen shots or even submit a patch for the bug.

When finished, click 'Submit Bug Report'.

Apport is launched automatically when a crash occurs as a result of segmentation violation, bus error, floating point exception, etc, but sometimes bugs occur in more minor ways that will not trigger apport. For example perhaps you find a menu item which does not work as expected or problems with the interface. These may not crash the program but need to be reported so they can be fixed.

First go here and check if a specific bug has already been reported for your version of Ubuntu.

Use Alt+F2 to open the 'Run Application' window and type ubuntu-bug <package name> or for a running application, open your System Monitor (System > Administration > System Monitor) and note the process ID number. Enter the process ID into Run Applications instead of the package name for example, 'ubuntu-bug 1664'.

When should you not report a bug? Bug reports are not for support or feature requests or non-Ubuntu packages.

Even small bugs can make software seem unfinished and immature. Each bug squashed contributes to the overall quality of all open source software and enhances its' credibility with the public.

Filing bug reports is an important part of being an involved member of the Linux community. Apport makes it simple to do your part.



This article was originally published in UbuntuManual.org on Sept. 30, 2011