Running a Linux Desktop Does Not Equal Security Part 3

Previously:

Part 1 and Part 2

I have never believed any of the periodic nonsense about "This is the year of the Linux desktop." There are significant deployments, but even 10% market share is probably several years away. Meaning it may never happen. While I like KDE I don't regard this as necessarily bad. As I mentioned previously, obscurity continues to provide at least some measure of protection, from some adversaries.

Of course, the KDE project and probably the majority of KDE users will have a very different idea about the desirability of widespread deployment. So, here is something that might help that along, and I wish some other projects would it as well.

Present a Clean, Reliable Security Advisory Notification Mechanism

Other than in the personal/home use arena, and particularly in environments where there are relatively strict security policies, it is common for deployment teams, and/or any security team which may be tasked with advising them, to need all the notice that they can get. This includes notice which might occur before any update notifications from the final supplier of the software.

This is even being included in some compliance regimes. Here is a quote from the Payment Card Industry Data Security Standard (PCI-DSS), Version 2, Requirement 6.2. This is the October 2010 version, not the latest. I am using the version in which the language first appeared, in order to demonstrate that this is hardly a recent thing.

While it is important to monitor vendor announcements for news of vulnerabilities and patches related to their products, it is equally important to monitor common industry vulnerability news groups and mailing lists for vulnerabilities and potential workarounds that may not yet be known or resolved by the vendor.

Patching deadlines, by severity, are also quite common. The very first version of PCI-DSS established a one-month deadline for critical patches.

According to KDE Security Policy BugTraq and kde-announce@kde.org are the list announcement venues. I was unable to find the notification browsing the BugTraq archives, though I looked well back into October. I found a reference to Konversation, but that was posted by the Debian Project, not KDE. It looks as if the published Security Policy is not being followed in this respect.

While the appropriate announcement was present in the kde-announce archives, searching those kde-announce archives was problematic, in that using a subject of 'security', it turned up only the latest result.

Also according to KDE Security Policy, "All security alerts are published on http://www.kde.org/info/security/." That page currently contains about 80 alerts, so it seems a more reliable data source. Which means security teams should probably write a scraper/parser/notifier for it. And compare it's output from final-supplier notification channels over time. Trust is built slowly, especially when there are existing problems.

Given lack of timely patching continues to cause an enormous amount of trouble for all concerned (it has been responsible for a large number of breaches) it would have been nice if I could have delivered a glowing report regarding KDE. Or at least their notification system. Unfortunately, I can't.

Running a Linux Desktop Does Not Equal Security Part 2

November 11, 2014 update:
Part 3 is available.

Yesterday I posted Running a Linux Desktop Does Not Equal Security ending under a heading of Even a Less-Popular Desktop, on a Less-Popular OS, Does Not Equal Security. I claimed that the sweet spot of combining a technologically advanced Linux desktop with the very real security advantage of obscurity is now over.

This has much to do with your expectations of who your attacker might be. In other words, your security model. I hope that your model is evolving as rapidly as the threat, but there is much evidence, (the failure of various compliance regimes, such as PCI comes to mind) that in general terms, security models suffer from significant lag.

For instance, if you are reading this post, you are likely being targeted by the NSA. I almost certainly am. While I find this beyond annoying as hell, that doesn't matter in this context. What matters more is NSA are past masters at traffic analysis, and are known to target systems administrators, anyone connected with crypto, and even readers of Linux Journal. That probably covers the vast majority of my audience, if “vast” is an appropriate term for a subset of very small set. A sliver of a sliver, if you will.

The thing is, NSA has the capability, and are known to exercise it. So, I have to classify an agency of my own government as an adversary. Insert Grrrr, howls of FUBAR, etc., but that is not the point here. At least these Bad Guys are Our Bad Guys. The United States is not the only nation-state in the world, and the resources that nearly any nation-state can bring to bear are huge. Even tiny hermit-kingdoms such as North Korea can field significant resources, and may have significant reasons, such as a lack of foreign currency, to do so.

It gets worse when you consider that organized crime is now building secure commercial exchanges, offering support for crimeware such as banking trojans, etc.

The resources available to adversaries have now become large enough that state-, quasi-state, and non-state threat actors can target even tiny slivers if they judge, for reasons that seem good to them, that there is a benefit. A successful attack, even if launched through a flawed rationale, is still a successful attack. Obscurity has lost some value. How much depends, again, on your security model.

Back to KDE on Linux

That is quite enough (probably to much) background. No commentary on overall Linux security, though this could certainly serve as an example of more widespread problems. That would be a whole other flight of posts. Let's get specific to KDE on Linux.

A few days ago, a problem with KDE Workspace surfaced. The relevant bits of

https://www.kde.org/info/security/advisory-20141106-1.txt

are (tpyos and all):

An application can gain root priveledges from an admin user with either misleading information or no interaction.

On some systems the user will be shown a prompt to change the time. However, if the system has policykit-desktop-privileges installed, the datetime helper will be invoked by an admin user without any prompts.

This is a code-injection attack, leading to privilege escalation., and KDE rated the risk as medium (whatever that means). I have several problems with this.

Some might think that this attack seems local, as opposed to something that can happen over the wire, hence not important on a laptop or workstation. The problem with that line of thought is that modern attacks are chained. The compromise of an unprivileged user account can be devastating, given how much sensitive information might be immediately compromised, and the historic difficulty of knowing the amount and sensitivity level of compromised data.

The trend is overwhelmingly compromise of user accounts via the Web browser, commonly the atrocity that is nearly any Adobe product that will run on Linux, Java plugins, etc. All the usual suspects, one of which gave me a foothold, albeit as 'only' your unprivileged user account. Because you weren't browsing the Web as root, because that would be supremely stupid.

Look at the above quote again, and consider the subtleties of prompting. As an attacker, who now has your privileges, I can to write into your KDE configuration files. I can now change the settings of your desktop clock to display time in something other than your local time zone. In short order, you will likely notice and be annoyed by this, and reset the time. Your system is now pwned, and I did not need to raise any sort of prompting dialog box, which might arouse suspicion. I only had to wait for you to prompt yourself, and contrary to the KDE alert, policykit-desktop-privileges was not required.

As a malicious root user, I will now be much harder to even detect. I'm in your kernel, or writing to flashable memory on your network card, or whatever. Eradicating me from your network might involve feeding the system into a shredder. And yes, you can shred entire systems these days. It's an expensive but available service. Desperate times, and all that.

Sadly, I Am Not Done Yet

Once again, this post has gone on for too long, other things need doing, and I haven't even touched on what might be done about the problem. I am going to have to do a Part 3, and yes, I suck as a blogger. Sorry about that. I am trying to suck less, if only because now I will have to edit the entire flight of posts on this topic to include links to updates and/or previous posts. Lack of expertise always carries a penalty.

November 11, 2014 update:
Part 3 is available.

Running a Linux Desktop Does Not Equal Security

Update Thursday, November 20, 2014
Part 2 is available.
November 11, 2014 update:
Part 3 is available.

For years, there have been a lot of silly things written by 'fans'. The Microsoft people versus the Mac people, etc. It took years to get the Mac people to shut up, and it may take more years to get the Linux crowd to similarly STFU.

Much of this is about Security by Obscurity. When Macs were rare, they were seldom attacked. Arguments were mounted about the inherent superiority of the BSD-derived OS, etc. These days, both operating systems are being hacked left and right, so the point is moot.

Still, the Linux fans persist, in some circles, with that same inherent superiority argument. There are valid reasons to favor Linux, but this is not one of them. Linux is being being hacked left and right as well, and 'fan' behavior is just random Internet Drama. Otherwise known as noise.

Security by Obscurity is often derided by the clueless as something to be avoided at all costs. Let's put that to rest straight off. It's an entirely valid defense, as evidenced, for example, by the well documented reductions of attacks resulting from the running of SSH servers on ports other than 22.

Security by Obscurity becomes a problem when it constitutes the majority of a defense strategy. If it is your sole defense, I am very glad that I am not you.

So What is Obscure?

The Linux desktop is, of course, fragmented. For years, Gnome ruled. Some of this was due to freakish historic accident: Linux taking market share from commercial UNIX, etc. At one point HP announced that HP-UX would feature Gnome as their replacement for CDE. Later this was quietly withdrawn.

The KDE desktop has a long history as well, with a surge in popularity in about 2000, with KDE 2. However, Red Hat chose Gnome.. They had to bottom out on something, as they were all about support, and Gnome had more mind-share.

KDE is not obscure, but to this day it does not have the mind-share that Gnome does. Which is a shame, in some respects, but not in others, precisely because it was less popular.

Even a Less-Popular Desktop, on a Less-Popular OS, Does Not Equal Security

KDE used to be a great work-station trade-off. Technologically advanced, easy to work with, yet almost never exploited. So, similar to the way Mac fans thought of their OS, but with a slightly better grounding in fact.

That sweet spot, such that it was, is now over. This post is already dry, and boring. I'll post a Part 2 tomorrow.

Update Thursday, November 20, 2014
Part 2 is available.
November 11, 2014 update:
Part 3 is available.

Expect An Increase in Russian Attacks

Some are probably seeing it already. Others will shortly. This is an easy prediction to make, as attacks arriving over the wire are more deniable, avoid much of the potential for the ugliness of arrests, expulsions of diplomats, and the general mayhem of old-school espionage. They also seem likely to be more generally useful, in terms of cost-effectiveness.

Yet old-school Russian espionage is on the rise, seemingly triggered by geopolitics, particularly the Ukraine debacle in this case, as has happened for centuries. Consider these recent news reports.

http://abcnews.go.com/International/wireStory/poles-russians-expel-diplomats-spying-26963002:

Poland expels diplomats for “activities incompatible with their status”, and Russia follows suit. All very old-school. There is also some information from the Czech counter-intelligence agency here.

http://time.com/3590588/putin-merkel-germany-russia/:

Goes into some depth about trade relations, and Germany abandoning their former stance of economic pragmatism, the extent of Russia's isolation, and whether that will actually matter.

http://www.spiegel.de/international/europe/germany-worried-about-russian-influence-in-the-balkans-a-1003427.html:

Reports that German Chancellor Angela Merkel has developed a fundamental distrust of Putin, and is concerned about the Balkans. So Serbia and Bosnia-Herzegovina. Even Bulgaria, just to the east of the Balkans, is a matter of concern.

Russia Has Significant Capabilities

This dates back for many years. I don't want to go all cyber-war here. That concept was at least partially hype from the start. Even the issues of Russian involvement in Estonia (widely held up as the first example of cyber-war) and Georgia are not nearly so clear-cut as they are made out to be by some parties.

That said, a criminal organization know as the Russian Business Network operated with a degree of impunity that would have been impossible without some sort of governmental relationship from 2006-2007 or so. The RBN was highly effective, offering services and software, and spawned many offshoots. It figured prominently in various security vendor reports for a number years dating from that time. It is probably safe to say that knowledge of the effectiveness of over-the-wire techniques has been known very well within the Russian government from at least that long ago.

Who Should be Concerned?

Pretty much anyone. Given the value of economic espionage, potential victims are not limited to, say, defense contractors. Even agricultural forecasts have figured prominently in relations between the US and Russia in the past. Obviously there are good reasons to believe that EU members should be even more concerned, particularly governmental organizations that touch on foreign policy, and business enterprises in the energy sector, or that do a significant export business (whether that currently involves Russia, or not).

The RBN had significant capabilities in the fundamental building blocks that are used to modern attacks, such as malware obfuscation and phishing. These techniques are important because they are proven.

Individuals should be concerned about the broad spectrum of social engineering attacks such as phishing emails, or simple requests for access from someone purporting to be working from home.

Security groups within organizations can mostly only do what they have always done, though hopefully with a bit more effectiveness, given the likelihood of trouble. Monitor for data exfiltration, audit systems and networks for compliance with the security posture you think you have. Patch.

One thing that seems to be little stressed is to speak with the people on the business side of things. You may discover that there is something about current negotiations, competitors, or simply the essential function of your organization (advocacy, etc.) which now makes you a more valuable target.

Raising awareness has historically failed, but it must still be attempted. Which is how this post came to be.

I Wish Spam Nation Had Been Published a Few Months Ago

My pre-ordered copy doesn't arrive until 11/24. It's on sale now, though, and you can get it next-day if you want. Amazon currently shows it to be in first place amongst network security books.

Truthfully, I don't expect it to contain any revelation which might have made all the difference had the book arrived today instead of on the the 24th. I am already well enough acquainted with the situation that it won't probably won't affect me from an operations perspective. Still, you can never have too much much knowledge, and the day will come when what Krebs knows will help me build a business case for better tooling, an idea which should appear in a better training programming, or who knows what.

I'm looking forward it.

NOAA Can't Predict Weather, Can't Secure Their Systems

NOAA is the The National Oceanic and Atmospheric Administration. It's part of the Department of Commerce, and contains the following "Line Offices"

• The National Oceanic and Atmospheric Administration
• National Environmental Satellite, Data, and Information Service
• National Marine Fisheries Service
• National Ocean Service
• National Weather Service
• Office of Oceanic and Atmospheric Research
• Office of Program Planning and Integration

Of course, there is a lot more stuff in there. Here are a couple of examples. The National Environmental Satellite, Data, and Information Service (NESDIS) provides feeds to the Navy and Air Force weather prediction systems, and the National Ocean Service (NWS). The NWS operates the Space Weather Prediction Center, which is of interest to operators of communications systems and and/or satellites, and the forecasts that your favorite broadcast news outlet likely reads and embellishes. Plus things like The Storm Prediction Center (useful to those of you in tornado country), and The National Hurricane Center (ditto for anyone on or near the Atlantic or Gulf coasts).

It's important.

I have a bit of a problem with NOAA, or least the NWS piece of it, because they can't seem to predict the weather. I don't expect miracles; accurate prediction for much more than a week in the future is impossible due to the nature of complex dynamical systems with a sensitive dependence on initial conditions. read any good reference on Chaos Theory. Personally, I enjoyed CHAOS Making a New
Science by James Gleick. Chaos Theory was pioneered by Edward Lorenz, a mathematician and meteorologist who was trying to model simple weather on an early computer at MIT.

So, this stuff was invented here in the US. Though lately we have fallen behind, as we have in so many other areas.

I can offer an example of that with the NWS having completely blown my local forecast (not an unusual thing) for the past couple of days with temperature misses on both the high (at least one) and low (2) sides. When they forecast 22°F, and it doesn't even freeze, that is a blown forecast.

It's even important enough that we should keep those systems secure, and indeed the federal government is required to secure their systems by the Federal Information Security Management Act of 2002. Here is U.S. Code, Title 44, Chapter 35,  Subchapter III, § 3541

The purposes of this subchapter are to—

(1) provide a comprehensive framework for ensuring the effectiveness of information security controls over information resources that support Federal operations and assets;

(2) recognize the highly networked nature of the current Federal computing environment and provide effective governmentwide management and oversight of the related information security risks, including coordination of information security efforts throughout the civilian, national security, and law enforcement communities;

(3) provide for development and maintenance of minimum controls required to protect Federal information and information systems;

(4) provide a mechanism for improved oversight of Federal agency information security programs;

(5) acknowledge that commercially developed information security products offer advanced, dynamic, robust, and effective information security solutions, reflecting market solutions for the protection of critical information infrastructures important to the national defense and economic security of the nation that are designed, built, and operated by the private sector; and

(6) recognize that the selection of specific technical hardware and software information security solutions should be left to individual agencies from among commercially developed products.

For a few years I tracked the report cards, which were created in addition to the Office of Management and Budget annual report to Congress. Here are the results for the Department of Commerce, which 'owns' NOAA.

2003	2004	2005	2006	2007
C-	F	D+	F	D+

Shortly after that the metrics were changed. In fairness, they needed to; threats and defenses were both evolving rapidly. And now most departments are doing at least fairly well. On paper, at least. I have my doubts, given the history of breaches, that they are they doing sufficiently well.

According to the most recent OMB report to Congress (FY 2013). 2328 security incidents were reported to US-CERT from Department of Commerce between 10/1/2012 and 9/30/13.

Is that datum worth anything? Are things reliably reported? According to Chinese hack U.S. weather systems, satellite network (Washington Post, November 12, 2014), NOAA managers are quite capable of covering up a breach which occurred in September, announcing only "unscheduled maintenance" in October, and failing to follow Department of Commerce  policy of notifying the Commerce Department Inspector General law enforcement within two days of any security incident, and notifying law enforcement.

The WaPo piece also mentions that NOAA declined to discuss any of this, or whether or not classified information was compromised. NOAA cited an ongoing investigation for not discussing it, and I am fine with that. But there was likely to have been another reason as well: they are in such horrible shape that they did, indeed could not, know fundamental things.

Two months before the breach, on July 15, 2014, The Office of Audit and Evaluation, part of the Department of Commerce Office of Inspector General, released
FINAL REPORT NO. OIG-14-025-A Significant Security Deficiencies in NOAA’s Information Systems Create Risks in Its National Critical Mission. This report is a bit of a horror story. For instance, 47% of their security control assessments were deficient, "... and may not have provided the AO with an accurate implementation status of the system’s security controls." Note that AO is jargon for 'authorizing official'; the person who signs the Authorization to Operate a government system.

So for some time, NOAA (specifically including the AO) did not accurately know their security posture, and did not know that they did did not know. Which made the Authorization to Operate less useful than a random piece of scrap paper, which is at least not actively damaging.

Coming on the heals of Monday's United States Postal Service breach, this does not inspire trust in government systems.

It Has Been a Long Couple of Weeks

Aaaand... I can't talk about the vast majority of it. Bummer, but also par for the course. So here are a couple of remarks about network time. Which seems to be something people take a bit too much for granted.

• I can mount a coherent argument that verifiable, accurate timekeeping is the most valuable service that modern networked systems provide, save authentication and authorization services. 
• It is likely that many (possibly a majority) of the designers and administrators of the systems that provide accurate network time do not understand common problems with ntpd WRT what they are actually trying to achieve, or evaluating the implications of moving to, say, chrony.

Just saying that for something as fundamental as I regard network timekeeping to be, sane behavior does not involve blind trust. It involves homework. The effort you can expend is of course directly proportional to how you weigh the criticality of network time. This obviously goes to the roots of estimating risk.

If you are confident that you have a good grip on this, and have considered it WRT to say, forensics and recoverability, fine. What I am worried about is that security professionals so often get trapped in a security trade-press news (are we safe from <recent news> questions) cycle. News, for at least a year now, has been worse than usual. That does not mean we can slack off on the fundamentals.