Ubuntu Updates for the Meltdown / Spectre Vulnerabilities

For up-to-date patch, package, and USN links, please refer to: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown

This is cross-posted on Canonical's official Ubuntu Insights blog:
https://insights.ubuntu.com/2018/01/04/ubuntu-updates-for-the-meltdown-spectre-vulnerabilities/

Unfortunately, you’ve probably already read about one of the most widespread security issues in modern computing history -- colloquially known as “Meltdown” (CVE-2017-5754) and “Spectre” (CVE-2017-5753 and CVE-2017-5715) -- affecting practically every computer built in the last 10 years, running any operating system. That includes Ubuntu.

I say “unfortunately”, in part because there was a coordinated release date of January 9, 2018, agreed upon by essentially every operating system, hardware, and cloud vendor in the world. By design, operating system updates would be available at the same time as the public disclosure of the security vulnerability. While it happens rarely, this an industry standard best practice, which has broken down in this case.

At its heart, this vulnerability is a CPU hardware architecture design issue. But there are billions of affected hardware devices, and replacing CPUs is simply unreasonable. As a result, operating system kernels -- Windows, MacOS, Linux, and many others -- are being patched to mitigate the critical security vulnerability.

Canonical engineers have been working on this since we were made aware under the embargoed disclosure (November 2017) and have worked through the Christmas and New Years holidays, testing and integrating an incredibly complex patch set into a broad set of Ubuntu kernels and CPU architectures.

Ubuntu users of the 64-bit x86 architecture (aka, amd64) can expect updated kernels by the original January 9, 2018 coordinated release date, and sooner if possible. Updates will be available for:

• Ubuntu 17.10 (Artful) -- Linux 4.13 HWE
• Ubuntu 16.04 LTS (Xenial) -- Linux 4.4 (and 4.4 HWE)
• Ubuntu 14.04 LTS (Trusty) -- Linux 3.13
• Ubuntu 12.04 ESM** (Precise) -- Linux 3.2
• Note that an Ubuntu Advantage license is required for the 12.04 ESM kernel update, as Ubuntu 12.04 LTS is past its end-of-life

Ubuntu 18.04 LTS (Bionic) will release in April of 2018, and will ship a 4.15 kernel, which includes the KPTI patchset as integrated upstream.

Ubuntu optimized kernels for the Amazon, Google, and Microsoft public clouds are also covered by these updates, as well as the rest of Canonical's Certified Public Clouds including Oracle, OVH, Rackspace, IBM Cloud, Joyent, and Dimension Data.

These kernel fixes will not be Livepatch-able. The source code changes required to address this problem is comprised of hundreds of independent patches, touching hundreds of files and thousands of lines of code. The sheer complexity of this patchset is not compatible with the Linux kernel Livepatch mechanism. An update and a reboot will be required to active this update.

Furthermore, you can expect Ubuntu security updates for a number of other related packages, including CPU microcode, GCC and QEMU in the coming days.

We don't have a performance analysis to share at this time, but please do stay tuned here as we'll followup with that as soon as possible.

Thanks,
@DustinKirkland
VP of Product
Canonical / Ubuntu

Ubuntu 16.04 LTS Security: A Comprehensive Overview

From Linux kernel livepatches to encryption to ASLR to compiler optimizations and configuration hardening, we strive to ensure that Ubuntu 16.04 LTS is the most secure Linux distribution out of the box.

These slides try to briefly explain:

• what we do to secure Ubuntu
• how the underlying technology works
• when the features took effect in Ubuntu

I hope you find this slide deck informative and useful!  The information herein is largely collected from the Ubuntu Security Features wiki page, where you can always find up to date information.

Ubuntu 16.04 LTS Security Features from Dustin Kirkland

Cheers,
Dustin

Dirty COW was Livepatched in Ubuntu within Hours of Publication

If you haven't heard about last week's Dirty COW vulnerability, I hope all of your Linux systems are automatically patching themselves...

Why?  Because every single Linux-based phone, router, modem, tablet, desktop, PC, server, virtual machine, and absolutely everything in between -- including all versions of Ubuntu since 2007 -- was vulnerable to this face-palming critical security vulnerability.

Any non-root local user of a vulnerable system can easily exploit the vulnerability and become the root user in a matter of a few seconds.  Watch...

Coincidentally, just before the vulnerability was published, we released the Canonical Livepatch Service for Ubuntu 16.04 LTS.  The thousands of users who enabled canonical-livepatch on their Ubuntu 16.04 LTS systems with those first few hours received and applied the fix to Dirty COW, automatically, in the background, and without rebooting!

If you haven't already enabled the Canonical Livepatch Service on your Ubuntu 16.04 LTS systems, you should really consider doing so, with 3 easy steps:

1. Go to https://ubuntu.com/livepatch and retrieve your livepatch token
2. Install the canonical-livepatch snap
   $ sudo snap install canonical-livepatch 
3. Enable the service with your token
   $ sudo canonical-livepatch enable [TOKEN]

And you’re done! You can check the status at any time using:

$ canonical-livepatch status --verbose

Let's retry that same vulnerability, on the same system, but this time, having been livepatched...

Aha!  Thwarted!

So that's the Ubuntu 16.04 LTS kernel space...  What about userspace?  Most of the other recent, branded vulnerabilities (Heartbleed, ShellShock, CRIME, BEAST) have been critical vulnerabilities in userspace packages.

As of Ubuntu 16.04 LTS, the unattended-upgrades package is now part of the default package set, so you should already have it installed on your Ubuntu desktops and servers.  If you don't already have it installed, you can install it with:

$ sudo apt install unattended-upgrades

And moreover, as of Ubuntu 16.04 LTS, the unattended-upgrades package automatically downloads and installs important security updates once per day, automatically patching critical security vulnerabilities and keeping your Ubuntu systems safe by default.  Older versions of Ubuntu (or Ubuntu systems that upgraded to 16.04) might need to enable this behavior using:

$ sudo dpkg-reconfigure unattended-upgrades

With that combination enabled -- (1) automatic livepatches to your kernel, plus (2) automatic application of security package updates -- Ubuntu 16.04 LTS is the most secure Linux distribution to date.  Period.

Mooooo,

:-Dustin

Ubuntu and XOR.DDoS -- Nothing to see here

I woke this morning to a series of questions about a somewhat sensationalist article published by ZDnet this morning: Linux-powered botnet generates giant denial-of-service attacks

All Linux distributions -- Ubuntu, Red Hat, and others -- enable SSH for remote server login.  That’s just a fact of life in a Linux-powered, cloud and server world.  SSH is by far the most secure way to administer a Linux machine remotely, as it leverages both strong authentication and encryption technology, and is actively reviewed and maintained for security vulnerabilities.

However, in Ubuntu, we have never in 11 years asked a user to set a root password by default, and as of Ubuntu 14.04 LTS, we now explicitly disable root password logins over SSH.

Any Ubuntu machine that might be susceptible to this XOS.DDoS attack, is in a very small minority of the millions of Ubuntu systems in the world.  Specifically, a vulnerable Ubuntu machine has been individually and manually configured by its administrator to:

1. permit SSH root password authentication, AND
2. have set a root password, AND
3. have chosen a poor quality root password that is subject to a brute force attack 

A poor password generally uses a simple dictionary word, or a short password without numbers, case sensitivity or symbols.

Moreover, the antivirus software ClamAV is freely available in Ubuntu (sudo apt-get install clamav), and is able to detect and purge XOR.DDoS from any affected system.

As a reminder, it’s important to:

• Always choose high quality passwords for all users on any computer system
• Avoid using SSH password authentication, in favor of SSH key authentication, whenever possible
• Ensure that all security patches are applied

For an exhaustive review of all Ubuntu security features, please refer to:

• https://wiki.ubuntu.com/Security/Features
• Ubuntu 14.04 LTS -- Security for Human Beings

Cheers,

Dustin

SXSW 2015 Slides and Audio from Fingerprints are Usernames, Not Passwords

This morning, I led a "core conversation" session in the Security and Privacy track at SXSW Interactive festival.  With 60 seats in the room, it was standing room only, and unfortunately, some people were turned away from the session due to a lack of space.  Amazingly, that was a packed house at 9:30am on a Sunday morning, merely stumbling distance from the late night party that is 6th Street in Austin, Texas!

I'm pleased to share with you both the slides, as well as a rudimentary audio recording from the mic on my laptop.  The format of a "core conversation" at SXSW is not your typical conference lecture.  Rather, it's an interactive, dynamic, social exchange of ideas and thoughts.  I hope you enjoy!

Slides:


Audio:


Have a great South-by!
Dustin

Security and Biometrics: SXSW Preview Q&A

Rebecca: Can you give me a brief overview of why you see it as a problem that our personal biometrics, at this point mostly fingerprints, are being used to authenticate our actions rather than identify us?

Dustin: How many emails have you received, to date, from some online service or another saying, "We're sorry, but our site was attacked, and while we don't think your password was compromised, we think you should change it anyway, for good measure"?

Surely you've seen this once or twice, right?  And if you're like me, you kind of take a deep breath, and think, "Oh man, that's inconvenient..."

Now, what if that site used some form of biometrics, instead.  Let's say your fingerprint.  Or your eyeball.  How would that email read? You want me to change my fingerprints!?!  My eyeballs!?!

That's ridiculous, of course, but it perfectly shows the problem. Biometrics are not changeable.  You couldn't alter them if you tried. Being able to change, rotate, and strengthen passwords is one of the
most fundamental properties of authentication tokens -- and completely missing from all forms of biometrics!

That's just one of a number of problems with biometrics.  I'll cover more in my talk ;-)

Rebecca: Is biometrics something you've worked with professionally or what has piqued your interest in the area?  What made you want to do a panel on the issue?

Dustin: Sort of.  I've long maintained and developed an encrypted filesystem for Linux, called eCryptfs.  In 2008, I was asked to add eCryptfs support for Thinkpad's fingerprint reader.  After thinking about it
for a while, I refused to do so, with the core arguments being much of what I described above.  With that refusal to support fingerprint readers in 2009, I seemed to have picked a few fights and arguments with various users.

All was pretty quiet on the home front, until Apple released an iPhone with a built-in fingerprint reader in late 2013, and I blogged this piece that criticized the idea accordingly: http://blog.dustinkirkland.com/2013/10/fingerprints-are-user-names-not.html

That blog post in October 2013 sort of did the viral thing on social media, I guess, seeing almost a million unique views in about a month.

Rebecca: I feel embarrassed to admit that I had simply never thought of this issue until seeing your panel synopsis.  Then, it seemed incredibly obvious and I found myself looking at my phone's fingerprint scanner suspiciously.  Why do you think the public has had so little response to biometrics in technology, other than seeing it as a neat feature of a particular gadget?

Dustin: On the surface, it seems like such a good idea.  We've all seen Mission Impossible or 007 or countless other spy movies where Hollywood portrays biometrics as the authentication mechanism of the future.  But it's just that...  Bad pulp fiction.

There are plenty of ideas that probably seemed like a good idea at first, right?  Examples: Clippy, The Hindenburg, New Coke, Tanning beds, The Shake Weight, Subprime Mortgages, Leaded Gasoline.  Think about for just a minute, though.  A passenger blimp filled with Hydrogen?  An annoying cartoon character that always knows more than you?  Massive scale lending to high-risk individuals packed into mortgage-backed securities?  Dig a little deeper and these were actually misapplications from the beginning.  We'll be in the same place with Biometrics, I have no doubt.

Rebecca: Have there been any instances that you're aware of where the technology has been compromised?

Dustin: The Chaos Computer Club have demonstrated compromised Apple TouchID: http://arstechnica.com/apple/2013/09/chaos-computer-club-hackers-trick-apples-touchid-security-feature/

TouchID is actually pretty high resolution.  The Thinkpad fingerprint readers, until recently, could be fooled with a piece of scotch tape: https://pacsec.jp/psj06/psj06krissler-e.pdf

Rebecca: In the future, if we continue down the current path do you see identity theft including the hacking of our fingerprints and voice patterns in addition to our credit card info?

Dustin: I certainly hope we can curtail this doomed path of technology before we get to that point...

But if we don't, then yes, absolutely.  All of your biometrics are easily collected in public places, with your knowledge.

• Your fingerprints are on your coffee mug and every beer bottle you've ever picked up with your bare hands.
• Your hair, dandruff, and dead skin contain your DNA.
• High resolution digital cameras can pick up your iris in incredible detail (less so for the retina currently)
• Facial recognition -- seriously, unless you've taken exorbitant steps, your face is all over Facebook, Google, LinkedIn, etc., and everywhere you go in public today, there are security monitors.
• The same goes for vocal recognition.  Surely you've heard, "This call may be recorded for training purposes".  Sure, that's fine.  But do you go spilling your master password to all of your accounts to that phone support?  Well, if you use voice recognition for your authentication, then that's exactly what you've done.

Rebecca: Beyond crime, what are the civil liberties issues you see being entwined with biometrics technology?  Could the government theoretically access this information in much the same way they have our email and phone records in the past?

Dustin: Theoretically, yes.  That that "theoretically, yes" is enough for me to be very concerned.

Is Apple colluding with the NSA/FBI/CIA/etc?  I am most certainly NOT making that accusation.

Could they, or anyone else in this biometrics?  Most certainly.  They could even be coerced or forced to do so.  And they could so unknowingly.  And it might not even be "the good guys".  Anyone of this magnitude is a target for attacks, by less than savory governments or crime organizations.

Moreover, I strongly recommend that everyone consider their biometrics compromised.  As I said above, you leave a trail of your fingerprints, DNA, face, voice, etc. everywhere you go.  Just accept that they're not secret, and don't pretend that they are :-)

Rebecca: What are some places where you see biometrics as appropriate and useful?

Dustin: Back to the title of the presentation, I think biometrics are decent as a "username", just not as a "password".

Is your name secret?  No, not really.  Is your email address secret? No, not really, either.

That's what biometrics are -- they're another expression of your "identity".  It can be used to replace, or rather, look up your name, username, or email address from a list, as it's just another expression of that information.

Now, a password is something entirely different.  A password is how you "prove" your identity.  This is something entirely different.  It must be long, and very hard to guess.  You have to be able to change it.  And you have to keep your passwords separate from different accounts, so that no one account could share that with another account and compromise you.

Rebecca: What are your thoughts on SXSW Interactive as a venue for such discussion?

Dustin: I think it's a fantastic venue!  I attended SXSW Interactive in 2014, and was very impressed with the quality of speakers and discussion around security, privacy, identity, and civil liberties.  I immediately regretted that I didn't submit this talk for the 2014 conference, and resolved to definitely do so for 2015.  Unfortunately, this subject is still important and topical in 2015 :-(  Which means we still have some work to do!

Rebecca: Finally, are there any other panels you're especially looking forward to?

Dustin: All of the Open Source ones (of which there are a lot!), as that's really my passion.  If I have to pick three right now I'm definitely attending, it would be:

• http://schedule.sxsw.com/2015/events/event_IAP35935
• http://schedule.sxsw.com/2015/events/event_IAP36290
• http://schedule.sxsw.com/2015/events/event_IAP40528

Cheers,
Dustin

Apply updates to multiple systems simultaneously using Byobu and Shift-F9

A StackExchange question, back in February of this year inspired a new feature in Byobu, that I had been thinking about for quite some time:

Wouldn't it be nice to have a hot key in Byobu that would send a command to multiple splits (or windows?

This feature was added and is available in Byobu 5.73 and newer (in Ubuntu 14.04 and newer, and available in the Byobu PPA for older Ubuntu releases).

I actually use this feature all the time, to update packages across multiple computers.  Of course, Landscape is a fantastic way to do this as well.  But if you don't have access to Landscape, you can always do this very simply with Byobu!

Create some splits, using Ctrl-F2 and Shift-F2, and in each split, ssh into a target Ubuntu (or Debian) machine.

Now, use Shift-F9 to open up the purple prompt at the bottom of your screen.  Here, you enter the command you want to run on each split.  First, you might want to run:

sudo true

This will prompt you for your password, if you don't already have root or sudo access.  You might need to use Shift-Up, Shift-Down, Shift-Left, Shift-Right to move around your splits, and enter passwords.

Now, update your package lists:

sudo apt-get update

And now, apply your updates:

sudo apt-get dist-upgrade

Here's a video to demonstrate!


In a related note, another user-requested feature has been added, to simultaneously synchronize this behavior among all splits.  You'll need the latest version of Byobu, 5.87, which will be in Ubuntu 14.10 (Utopic).  Here, you'll press Alt-F9 and just start typing!  Another demonstration video here...




Cheers,
Dustin

Ubuntu 14.04 LTS -- Security for Human Beings

In about an hour, I have the distinct honor to address a room full of federal sector security researchers and scientists at the US Department of Energy's Oak Ridge National Labs, within the Cyber and Information Security Research Conference.

I'm delighted to share with you the slide deck I have prepared for this presentation.  You can download a PDF here.

To a great extent, I have simply reformatted the excellent Ubuntu Security Features wiki page our esteemed Ubuntu Security Team maintains, into a format by which I can deliver as a presentation.

Hopefully you'll learn something!  I certainly did, as I researched and built this presentation ;-)

On a related security note, it's probably worth mentioning that Canonical's IS team have updated all SSL services with patched OpenSSL from the Ubuntu security archive, and have restarted all relevant services (using Landscape, for the win), against the Heartbleed vulnerability. I will release an updated pollinate package in a few minutes, to ship the new public key for entropy.ubuntu.com.

Stay safe,
Dustin

Improving Random Seeds in Ubuntu 14.04 LTS Cloud Instances

Tomorrow, February 19, 2014, I will be giving a presentation to the Capital of Texas chapter of ISSA, which will be the first public presentation of a new security feature that has just landed in Ubuntu Trusty (14.04 LTS) in the last 2 weeks -- doing a better job of seeding the pseudo random number generator in Ubuntu cloud images.  You can view my slides here (PDF), or you can read on below.  Enjoy!

Q: Why should I care about randomness? 

A: Because entropy is important!

• Choosing hard-to-guess random keys provide the basis for all operating system security and privacy
• SSL keys
• SSH keys
• GPG keys
• /etc/shadow salts
• TCP sequence numbers
• UUIDs
• dm-crypt keys
• eCryptfs keys
• Entropy is how your computer creates hard-to-guess random keys, and that's essential to the security of all of the above

Q: Where does entropy come from?

A: Hardware, typically.

• Keyboards
• Mouses
• Interrupt requests
• HDD seek timing
• Network activity
• Microphones
• Web cams
• Touch interfaces
• WiFi/RF
• TPM chips
• RdRand
• Entropy Keys
• Pricey IBM crypto cards
• Expensive RSA cards
• USB lava lamps
• Geiger Counters
• Seismographs
• Light/temperature sensors
• And so on

Q: But what about virtual machines, in the cloud, where we have (almost) none of those things?

A: Pseudo random number generators are our only viable alternative.

• In Linux, /dev/random and /dev/urandom are interfaces to the kernel’s entropy pool
• Basically, endless streams of pseudo random bytes
• Some utilities and most programming languages implement their own PRNGs
• But they usually seed from /dev/random or /dev/urandom
• Sometimes, virtio-rng is available, for hosts to feed guests entropy
• But not always

Q: Are Linux PRNGs secure enough?

A: Yes, if they are properly seeded.

• See random(4)
• When a Linux system starts up without much operator interaction, the entropy pool may be in a fairly predictable state
• This reduces the actual amount of noise in the entropy pool below the estimate
• In order to counteract this effect, it helps to carry a random seed across shutdowns and boots
• See /etc/init.d/urandom

...
dd if=/dev/urandom of=$SAVEDFILE bs=$POOLBYTES count=1 >/dev/null 2>&1 

...

Q: And what exactly is a random seed?

A: Basically, its a small catalyst that primes the PRNG pump.

• Let’s pretend the digits of Pi are our random number generator
• The random seed would be a starting point, or “initialization vector”
• e.g. Pick a number between 1 and 20
• say, 18
• Now start reading random numbers

• Not bad...but if you always pick ‘18’...

XKCD on random numbers

RFC 1149.5 specifies 4 as the standard IEEE-vetted random number.

Q: So my OS generates an initial seed at first boot?

A: Yep, but computers are predictable, especially VMs.

• Computers are inherently deterministic
• And thus, bad at generating randomness
• Real hardware can provide quality entropy
• But virtual machines are basically clones of one another
• ie, The Cloud
• No keyboard or mouse
• IRQ based hardware is emulated
• Block devices are virtual and cached by hypervisor
• RTC is shared
• The initial random seed is sometimes part of the image, or otherwise chosen from a weak entropy pool

Dilbert on random numbers

Q: Surely you're just being paranoid about this, right?

A: I’m afraid not...

Analysis of the LRNG (2006)

• Little prior documentation on Linux’s random number generator
• Random bits are a limited resource
• Very little entropy in embedded environments
• OpenWRT was the case study
• OS start up consists of a sequence of routine, predictable processes
• Very little demonstrable entropy shortly after boot
• http://j.mp/McV2gT

Black Hat (2009)

• iSec Partners designed a simple algorithm to attack cloud instance SSH keys
• Picked up by Forbes
• http://j.mp/1hcJMPu

Factorable.net (2012)

• Minding Your P’s and Q’s: Detection of Widespread Weak Keys in Network Devices
• Comprehensive, Internet wide scan of public SSH host keys and TLS certificates
• Insecure or poorly seeded RNGs in widespread use
• 5.57% of TLS hosts and 9.60% of SSH hosts share public keys in a vulnerable manner
• They were able to remotely obtain the RSA private keys of 0.50% of TLS hosts and 0.03% of SSH hosts because their public keys shared nontrivial common factors due to poor randomness
• They were able to remotely obtain the DSA private keys for 1.03% of SSH hosts due to repeated signature non-randomness
• http://j.mp/1iPATZx

Dual_EC_DRBG Backdoor (2013)

• Dual Elliptic Curve Deterministic Random Bit Generator
• Ratified NIST, ANSI, and ISO standard
• Possible backdoor discovered in 2007
• Bruce Schneier noted that it was “rather obvious”
• Documents leaked by Snowden and published in the New York Times in September 2013 confirm that the NSA deliberately subverted the standard
• http://j.mp/1bJEjrB

Q: Ruh roh...so what can we do about it?

A: For starters, do a better job seeding our PRNGs.

• Securely
• With high quality, unpredictable data
• More sources are better
• As early as possible
• And certainly before generating
• SSH host keys
• SSL certificates
• Or any other critical system DNA
• /etc/init.d/urandom “carries” a random seed across reboots, and ensures that the Linux PRNGs are seeded

Q: But how do we ensure that in cloud guests?

A: Run Ubuntu!

Sorry, shameless plug...

Q: And what is Ubuntu's solution?

A: Meet pollinate.

• pollinate is a new security feature, that seeds the PRNG.
• Introduced in Ubuntu 14.04 LTS cloud images
• Upstart job
• It automatically seeds the Linux PRNG as early as possible, and before SSH keys are generated
• It’s GPLv3 free software
• Simple shell script wrapper around curl
• Fetches random seeds
• From 1 or more entropy servers in a pool
• Writes them into /dev/urandom
• https://launchpad.net/pollinate

Q: What about the back end?

A: Introducing pollen.

• pollen is an entropy-as-a-service implementation
• Works over HTTP and/or HTTPS
• Supports a challenge/response mechanism
• Provides 512 bit (64 byte) random seeds
• It’s AGPL free software
• Implemented in golang
• Less than 50 lines of code
• Fast, efficient, scalable
• Returns the (optional) challenge sha512sum
• And 64 bytes of entropy
• https://launchpad.net/pollen

Q: Golang, did you say?  That sounds cool!

A: Indeed. Around 50 lines of code, cool!

pollen.go

Q: Is there a public entropy service available?

A: Hello, entropy.ubuntu.com.

• Highly available pollen cluster
• TLS/SSL encryption
• Multiple physical servers
• Behind a reverse proxy
• Deployed and scaled with Juju
• Multiple sources of hardware entropy
• High network traffic is always stirring the pot
• AGPL, so source code always available
• Supported by Canonical
• Ubuntu 14.04 LTS cloud instances run pollinate once, at first boot, before generating SSH keys

Q: But what if I don't necessarily trust Canonical?

A: Then use a different entropy service :-)

• Deploy your own pollen
• bzr branch lp:pollen
• sudo apt-get install pollen
• juju deploy pollen
• Add your preferred server(s) to your $POOL
• In /etc/default/pollinate
• In your cloud-init user data
• In progress
• In fact, any URL works if you disable the challenge/response with pollinate -n|--no-challenge
• random.org
• news.google.com
• Or whatever site you like

Q: So does this increase the overall entropy on a system?

A: No, no, no, no, no!

• pollinate seeds your PRNG, securely and properly and as early as possible
• This improves the quality of all random numbers generated thereafter
• pollen provides random seeds over HTTP and/or HTTPS connections
• This information can be fed into your PRNG
• The Linux kernel maintains a very conservative estimate of the number of bits of entropy available, in /proc/sys/kernel/random/entropy_avail
• Note that neither pollen nor pollinate directly affect this quantity estimate!!!

Q: Why the challenge/response in the protocol?

A: Think of it like the Heisenberg Uncertainty Principle.

• The pollinate challenge (via an HTTP POST submission) affects the pollen's PRNG state machine
• pollinate can verify the response and ensure that the pollen server at least “did some work”
• From the perspective of the pollen server administrator, all communications are “stirring the pot”
• Numerous concurrent connections ensure a computationally complex and impossible to reproduce entropy state

Q: What if pollinate gets crappy or compromised or no random seeds?

A: Functionally, it’s no better or worse than it was without pollinate in the mix.

• In fact, you can `dd if=/dev/zero of=/dev/random` if you like, without harming your entropy quality
• All writes to the Linux PRNG are whitened with SHA1 and mixed into the entropy pool
• Of course it doesn’t help, but it doesn’t hurt either
• Your overall security is back to the same level it was when your cloud or virtual machine booted at an only slightly random initial state
• Note the permissions on /dev/*random
• crw-rw-rw- 1 root root 1, 8 Feb 10 15:50 /dev/random
• crw-rw-rw- 1 root root 1, 9 Feb 10 15:50 /dev/urandom
• It's a bummer of course, but there's no new compromise

Q: What about SSL compromises, or CA Man-in-the-Middle attacks?

A: We are mitigating that by bundling the public certificates in the client.

• The pollinate package ships the public certificate of entropy.ubuntu.com
• /etc/pollinate/entropy.ubuntu.com.pem
• And curl uses this certificate exclusively by default
• If this really is your concern (and perhaps it should be!)
• Add more URLs to the $POOL variable in /etc/default/pollinate
• Put one of those behind your firewall
• You simply need to ensure that at least one of those is outside of the control of your attackers

Q: What information gets logged by the pollen server?

A: The usual web server debug info.

• The current timestamp
• The incoming client IP/port
• At entropy.ubuntu.com, the client IP/port is actually filtered out by the load balancer
• The browser user-agent string
• Basically, the exact same information that Chrome/Firefox/Safari sends
• You can override if you like in /etc/default/pollinate
• The challenge/response, and the generated seed are never logged!

Feb 11 20:44:54 x230 2014-02-11T20:44:54-06:00 x230 pollen[28821] Server received challenge from [127.0.0.1:55440, pollinate/4.1-0ubuntu1 curl/7.32.0-1ubuntu1.3 Ubuntu/13.10 GNU/Linux/3.11.0-15-generic/x86_64] at [1392173094634146155]

Feb 11 20:44:54 x230 2014-02-11T20:44:54-06:00 x230 pollen[28821] Server sent response to [127.0.0.1:55440, pollinate/4.1-0ubuntu1 curl/7.32.0-1ubuntu1.3 Ubuntu/13.10 GNU/Linux/3.11.0-15-generic/x86_64] at [1392173094634191843]

Q: Have the code or design been audited?

A: Yes, but more feedback is welcome!

• All of the source is available
• Service design and hardware specs are available
• The Ubuntu Security team has reviewed the design and implementation
• All feedback has been incorporated
• At least 3 different Linux security experts outside of Canonical have reviewed the design and/or implementation
• All feedback has been incorporated

Q: Where can I find more information?

A: Read Up!

• Ubuntu Security
• https://wiki.ubuntu.com/Security/Features
• Browse code and file bugs
• https://launchpad.net/pollen
• https://launchpad.net/pollinate
• Documentation
• http://manpg.es/pollinate.1
• http://manpg.es/pollen.8

Stay safe out there!
:-Dustin

Is privacy really yours?

I'm trying desperately to hold private my opinions about the latest revelations on the ways and means of modern espionage, its targets, and rationalizations.

But I find this logic, from Congressman Mike Rogers, Chairman of the House Intelligence committee, quite dangerous...

He says, and I quote:

"You can't have your privacy violated if you don't know your privacy is violated".

While the United States laws on privacy are complicated, I feel that this is so awfully wrong :-(

Criminal voyeurism is illegal.  Date rape is illegal.  This is not a thought experiment.  If a tree falls in the forest, there is a tree on the ground irrespective of its audiology.

Comprehend Congressman Rogers' same logic applied to Rohypnol.  Or a video camera hidden in a dressing room.  These are blatant crimes, whether or not the victims are aware of the violations of their privacy.

This recent TED talk, by Mikko Hypponen, is incredibly thought provoking.  Chillingly, he quips, "Orwell was an optimist".  Yikes.  On a happier note, I'm almost positive his slides in this talk use the Ubuntu font.  Presumably he delivered this presentation in Brussells from an Ubuntu PC?




Dustin

Data Security and Key Management in the Cloud

Key management in cloud computing presents a brand new, unique, and distinct set of challenges which are in many cases disparate from the traditional set of key management problems system administrators have been dealing with for decades in physical data centers.  In fact, this very topic, in conjunction with data security and privacy, is the subject of two presentations I’m giving in the next 30 days at:

• Texas Linux Fest -- San Antonio, TX -- August 4, 2012
• Linux Foundation’s CloudOpen -- San Diego, CA -- Wednesday August 29, 2012

How are you managing your most sensitive information stored in the Cloud? Are you encrypting that data? Where are you storing your cryptographic keys and certificates? And who has access to them? If you have a stake in your organization's security, these questions may be keeping you up at night.

Cloud storage and Big Data present significant opportunities for enterprises, but those opportunities bring several huge challenges. In this session, we’ll explore:

• What's not secure, not acceptable, not working --- but totally pervasive!
• Where encryption makes the most sense around Cloud and Big Data applications
• Key sprawl in the cloud
• The strengths and weaknesses of various key management options
• Easing the pain - Recent innovations for managing keys and company secrets
• Real-world use cases – from web servers to encrypted file systems to big data to SSH to SSL

I hope you’ll join me for one or both of these talks!

:-Dustin

UDS Video: Security, Cloud, and Ubuntu

I stepped away from a busy schedule of awesome sessions the Ubuntu Developer Summit in Oakland, CA to speak for a few minutes about the requirement of "openness" in modern Cloud Computing, the absolute necessity of security and encryption of data, and benefits of Ubuntu as both a Cloud host and guest. Enjoy!

• https://pages.canonical.com/gazzang.html

If you're interested in learning more about security considerations when planning your cloud or big data deployment, consider subscribing to Gazzang's blog feed, or reading some of our white papers.

Cheers!
:-Dustin

Gazzang Presents: Sh*t IT Security Guys Say

We had a blast at the Gazzang offices last week shooting this fun video, Sh*t IT Security Guys Say.  What a great way to kick back and have a little fun on a Friday afternoon ;-)






We worked with Austin filmmaker Brandon Stephens who took some time away from work on his feature film, Enemy of the Mind, to hack on this little project.  Our CEO Larry Warnock (Mr. Backdoor) called the shots and our new Marketing Director, David Tishgart (Mr. Redbull) handled the script.  Also featured in the short: Ben First (Marketing, aka Mr. Ruby), Liz Britain (Marketing, aka Ms. Slashdot), Rob Balena (Sales, aka Mr. Millennium Falcon), Sergio Pena (Mr. $*&%!#), Eddie Garcia (Engineering, aka Mr. IT), and I guess I'm Mr. Wingdings ;-)

As many of my fellow hackers, I predictably cringe when I watch a movie or a tv show and the hapless IT characters attempt to interface with a computer or discuss technology.  The Matrix, The Net, Swordfish, whatever, it's all painful to hear.  And funny enough, our little video is no different, and this time I actually share the blame :-)  Most of our one-liners make no IT sense whatsoever.  And while some of the one-liners I proposed made perfect IT/Security sense, but they just didn't play well on the screen.

In any case, for my hacker/dev/IT peeps, here's my full list of one-liners I proposed for our project:

 - Right, RSA 4096 is definitely the way to go - Ubuntu or Fedora? - Did you read Bruce Schneier's post today? - Wow, check Slashdot! - Open a new terminal - Emacs or Vi? - Grab my public key - apt-get dist-upgrade - Sure, I encrypt my home directory - Hang on, I'm recompiling my kernel - PC Load letter????  The f*ck does that mean? - Yeah, I need to merge those changes - We're moving from MD5 to SHA512 hashes - Of course I've rooted my Android! - Chef or Puppet? - There's an XKCD about that :-) - Users, I swear...add it to the FAQ - Buffer overflow, uh oh... - Python or Perl?  Ruby!?! -- you gotta be kidding me :-( - You don't have to forward me that email.  I've already seen it.  You don't use email encryption :-) - Would you sign my public key? - Fire up an instance in EC2 - My kernel oops'd - TCP or UDP? - There's not enough entropy on this friggin machine! - You haven't rooted your phone? - No open access points?  I see 12 running WEP.  Give me a minute...  Okay, I'm in. - Where's your public key? - Drop that in a pastebin - Okay, I have it.  What's your fingerprint? - Java or C++? - What do you think of Unity? - OpenStack or Eucalyptus? - Check StackExchange - Shit, not another core dump...

I hope you enjoy watching it as much as we enjoyed making it!

Cheers!
:-Dustin