Security

Shrinking Linux Attack Surfaces

Zack Brown — Thu, 18 Jul 2019 11:00:00 +0000

Often, a kernel developer will try to reduce the size of an attack surface against Linux, even if it can't be closed entirely. It's generally a toss-up whether such a patch makes it into the kernel. Linus Torvalds always prefers security patches that really close a hole, rather than just give attackers a slightly harder time of it.

Matthew Garrett recognized that userspace applications might have secret data that might be sitting in RAM at any given time, and that those applications might want to wipe that data clean so no one could look at it.

There were various ways to do this already in the kernel, as Matthew pointed out. An application could use mlock() to prevent its memory contents from being pushed into swap, where it might be read more easily by attackers. An application also could use atexit() to cause its memory to be thoroughly overwritten when the application exited, thus leaving no secret data in the general pool of available RAM.

The problem, Matthew pointed out, came if an attacker was able to reboot the system at a critical moment—say, before the user's data could be safely overwritten. If attackers then booted into a different OS, they might be able to examine the data still stored in RAM, left over from the previously running Linux system.

As Matthew also noted, the existing way to prevent even that was to tell the UEFI firmware to wipe system memory before booting to another OS, but this would dramatically increase the amount of time it took to reboot. And if the good guys had won out over the attackers, forcing them to wait a long time for a reboot could be considered a denial of service attack—or at least downright annoying.

Ideally, Matthew said, if the attackers were only able to induce a clean shutdown—not simply a cold boot—then there needed to be a way to tell Linux to scrub all data out of RAM, so there would be no further need for UEFI to handle it, and thus no need for a very long delay during reboot.

Matthew explained the reasoning behind his patch. He said:

Unfortunately, if an application exits uncleanly, its secrets may still be present in RAM. This can't be easily fixed in userland (eg, if the OOM killer decides to kill a process holding secrets, we're not going to be able to avoid that), so this patch adds a new flag to madvise() to allow userland to request that the kernel clear the covered pages whenever the page reference count hits zero. Since vm_flags is already full on 32-bit, it will only work on 64-bit systems.

Matthew Wilcox liked this plan and offered some technical suggestions for Matthew G's patch, and Matthew G posted an updated version in response.

Go to Full Article

When Choosing Your Commercial Linux, Choose Wisely!

Vince Calandra — Wed, 17 Jul 2019 12:00:00 +0000

by Vince Calandra

“Linux is Linux is Linux,” is a direct quote I heard in a meeting I had recently with a major multi-national, critical-infrastructure company. Surprisingly and correctly, there was one intelligent and brave engineering executive who replied to this statement, made by one of his team members, with a resounding, “That’s not true.” Let’s be clear, selecting a commercial Linux is not like selecting corn flakes. This is especially true when you are targeting embedded systems. You must be considering key questions regarding the supplier of the distribution, the criticality of the target application, security and life-cycle support for your product.

Choose Wisely

There is a wonderful scene in the movie Indiana Jones and the Last Crusade when our hero, Indiana, must select the true Holy Grail. Set before him is a multitude of cups ranging from opulent, bejeweled challises to simple clay drinking cups. If you have seen the movie, Indiana reasons out the best choice, and it was a life or death selection. The knight who had been guarding the challises for centuries famously says, “You chose… wisely.” Why bring up this iconic scene? When you are selecting a commercial Linux distribution, you have a multitude of choices all bejeweled with wonderful marketing. The bottom line is that you want to save dollars that you would have otherwise spent on a DIY-Linux approach and ensure the commercial Linux selected fits your particular application. Here are some questions that you will need to keep in mind:

Is this for an IT application?
Is this for an OT (Operational Technology) application?
How long will this system be in the field?
What processes and procedures are used by my supplier to cover security vulnerabilities?
Can my supplier integrate in other Linux packages that support functionality I need going forward?

This is the short list. Other elements to keep in mind are the specific distribution’s origin and the Open Source community upon which it is based. How important is that specific Linux supplier with regard to the Open Source community upon which the distribution is based? These elements need to be part of the thought process.

I’ll Let My Silicon Choose

Go to Full Article

Address Space Isolation and the Linux Kernel

Zack Brown — Wed, 10 Jul 2019 11:30:00 +0000

by Zack Brown

Mike Rapoport from IBM launched a bid to implement address space isolation in the Linux kernel. Address space isolation emanates from the idea of virtual memory—where the system maps all its hardware devices' memory addresses into a clean virtual space so that they all appear to be one smooth range of available RAM. A system that implements virtual memory also can create isolated address spaces that are available only to part of the system or to certain processes.

The idea, as Mike expressed it, is that if hostile users find themselves in an isolated address space, even if they find bugs in the kernel that might be exploited to gain control of the system, the system they would gain control over would be just that tiny area of RAM to which they had access. So they might be able to mess up their own local user, but not any other users on the system, nor would they be able to gain access to root level infrastructure.

In fact, Mike posted patches to implement an element of this idea, called System Call Isolation (SCI). This would cause system calls to each run in their own isolated address space. So if, somehow, an attacker were able to modify the return values stored in the stack, there would be no useful location to which to return.

His approach was relatively straightforward. The kernel already maintains a "symbol table" with the addresses of all its functions. Mike's patches would make sure that any return addresses that popped off the stack corresponded to entries in the symbol table. And since "attacks are all about jumping to gadget code which is effectively in the middle of real functions, the jumps they induce are to code that doesn't have an external symbol, so it should mostly detect when they happen."

The problem, he acknowledged, was that implementing this would have a speed hit. He saw no way to perform and enforce these checks without slowing down the kernel. For that reason, Mike said, "it should only be activated for processes or containers we know should be untrusted."

There was not much enthusiasm for this patch. As Jiri Kosina pointed out, Mike's code was incompatible with other security projects like retpolines, which tries to prevent certain types of data leaks falling into an attacker's hands.

There was no real discussion and no interest was expressed in the patch. The combination of the speed hit, the conflict with existing security projects, and the fact that it tried to secure against only hypothetical security holes and not actual flaws in the system, probably combined to make this patch set less interesting to kernel developers.

Go to Full Article

Understanding Public Key Infrastructure and X.509 Certificates

Jeff Woods — Fri, 21 Jun 2019 12:30:00 +0000

by Jeff Woods

An introduction to PKI, TLS and X.509, from the ground up.

Public Key Infrastructure (PKI) provides a framework of encryption and data communications standards used to secure communications over public networks. At the heart of PKI is a trust built among clients, servers and certificate authorities (CAs). This trust is established and propagated through the generation, exchange and verification of certificates.

This article focuses on understanding the certificates used to establish trust between clients and servers. These certificates are the most visible part of the PKI (especially when things break!), so understanding them will help to make sense of—and correct—many common errors.

As a brief introduction, imagine you want to connect to your bank to schedule a bill payment, but you want to ensure that your communication is secure. "Secure" in this context means not only that the content remains confidential, but also that the server with which you're communicating actually belongs to your bank.

Without protecting your information in transit, someone located between you and your bank could observe the credentials you use to log in to the server, your account information, or perhaps the parties to which your payments are being sent. Without being able to confirm the identity of the server, you might be surprised to learn that you are talking to an impostor (who now has access to your account information).

Transport layer security (TLS) is a suite of protocols used to negotiate a secured connection using PKI. TLS builds on the SSL standards of the late 1990s, and using it to secure client to server connections on the internet has become ubiquitous. Unfortunately, it remains one of the least understood technologies, with errors (often resulting from an incorrectly configured website) becoming a regular part of daily life. Because those errors are inconvenient, users regularly click through them without a second thought.

Understanding the X.509 certificate, which is fully defined in RFC 5280, is key to making sense of those errors. Unfortunately, these certificates have a well deserved reputation of being opaque and difficult to manage. With the multitude of formats used to encode them, this reputation is rightly deserved.

An X.509 certificate is a structured, binary record. This record consists of several key and value pairs. Keys represent field names, where values may be simple types (numbers, strings) to more complex structures (lists). The encoding from the key/value pairs to the structured binary record is done using a standard known as ASN.1 (Abstract Syntax Notation, One), which is a platform-agnostic encoding format.

Go to Full Article

Why Smart Cards Are Smart

Kyle Rankin — Wed, 12 Jun 2019 11:30:00 +0000

by Kyle Rankin

If you use GPG keys, learn about the benefits to storing them on a smart card.

GPG has been around for a long time and is used to secure everything from your email to your software. If you want to send an email to someone and be sure that no one else can read or modify it, GPG signing and encryption are the main method you'd use. Distributions use GPG to sign their packages, so you can feel confident that the ones you download and install from a package mirror have not been modified from their original state. Developers in many organizations follow the best practice of GPG-signing any code they commit to a repository. By signing their commits, other people can confirm that the changes that claim to come from a particular developer truly did. Web-based Git front ends like GitHub and GitLab let users upload their GPG public keys, so when they do commit signed code, the interface can display to everyone else that it has been verified.

Yet, all of the security ultimately comes down to the security of your private key. Once others have access to your private key, they can perform all of the same GPG tasks as though they were you. This is why you are prompted to enter a passphrase when you first set up a GPG key. The idea is that if attackers are able to copy your key, they still would need to guess your password before they could use the key. For all of the importance of GPG key security, many people still just leave their keys in ~/.gnupg directories on their filesystem and copy that directory over to any systems where they need to use GPG.

There is a better way. With OpenPGP smart cards, you can store your keys on a secure device that's protected with a PIN and not only store your keys more securely, but also use them more conveniently. Although some laptops come with integrated smart card readers, most don't. Thankfully, these devices are available as part of multi-function USB security token devices from a number of different vendors, and Linux Journal has published reviews of such products in the past. In this article, I discuss all the reasons OpenPGP smart cards are a better choice for storing your keys than your local filesystem.

Reason 1: Tamper-proof Key Storage

One of the main benefits of a smart card is that it stores your GPG keys securely. When you store your keys on a filesystem, anyone who can access that filesystem can copy off the keys. On a smart card, once keys go in, they never leave, neither accidentally nor from tampering. The smart card chips themselves are designed to be tamper-proof and resist attempts to extract key data even when someone has physical access. By putting keys on a smart card, you can have a reasonable assurance that your keys are safe, even from a determined attacker.

Go to Full Article

Securing the Kernel Stack

Zack Brown — Tue, 11 Jun 2019 12:00:00 +0000

by Zack Brown

The Linux kernel stack is a tempting target for attack. This is because the kernel needs to keep track of where it is. If a function gets called, which then calls another, which then calls another, the kernel needs to remember the order they were all called, so that each function can return to the function that called it. To do that, the kernel keeps a "stack" of values representing the history of its current context.

If an attacker manages to trick the kernel into thinking it should transfer execution to the wrong location, it's possible the attacker could run arbitrary code with root-level privileges. Once that happens, the attacker has won, and the computer is fully compromised. And, one way to trick the kernel this way is to modify the stack somehow, or make predictions about the stack, or take over programs that are located where the stack is pointing.

Protecting the kernel stack is crucial, and it's the subject of a lot of ongoing work. There are many approaches to making it difficult for attackers to do this or that little thing that would expose the kernel to being compromised.

Elena Reshetova is working on one such approach. She wants to randomize the kernel stack offset after every system call. Essentially, she wants to obscure the trail left by the stack, so attackers can't follow it or predict it. And, she recently posted some patches to accomplish this.

At the time of her post, no specific attacks were known to take advantage of the lack of randomness in the stack. So Elena was not trying to fix any particular security hole. Rather, she said, she wanted to eliminate any possible vector of attack that depended on knowing the order and locations of stack elements.

This is often how it goes—it's fine to cover up holes as they appear, but even better is to cover a whole region so that no further holes can be dug.

There was a lot of interest in Elena's patch, and various developers made suggestions about how much randomness she would need, and where she should find entropy for that randomness, and so on.

In general, Linus Torvalds prefers security patches to fix specific security problems. He's less enthusiastic about adding security to an area where there are no exploits. But in this case, he may feel that Elena's patch adds a level of security that wasn't there before.

Security is always such a nightmare. Often, a perfectly desirable feature may have to be abandoned, not because it's not useful, but because it creates an inherent insecurity. Microsoft's operating system and applications often have suffered from making the wrong decisions in those cases—choosing to implement a cool feature in spite of the fact that it could not be done securely. Linux, on the other hand, and the other open-source systems like FreeBSD, never make that mistake.

Go to Full Article

WebAuthn Web Authentication with YubiKey 5

Todd A. Jacobs — Tue, 21 May 2019 12:00:00 +0000

by Todd A. Jacobs

A look at the recently released YubiKey 5 hardware authenticator series and how web authentication with the new WebAuthn API leverages devices like the YubiKey for painless website registration and strong user authentication.

I covered the YubiKey 4 in the May 2016 issue of Linux Journal, and the magazine has published a number of other articles on both YubiKeys and other forms of multi-factor authentication since then. Yubico recently has introduced the YubiKey 5 line of products. In addition to the YubiKey's long-time support of multiple security protocols, the most interesting feature is the product's new support for FIDO2 and WebAuthn.

WebAuthn is an application programming interface (API) for web authentication. It uses cryptographic "authenticators", such as a YubiKey 5 hardware token to authenticate users, in addition to (or even instead of) a typical user name/password combination. WebAuthn is currently a World Wide Web Consortium (W3C) candidate recommendation, and it's already implemented by major browsers like Chrome and Firefox.

This article provides an overview of the YubiKey 5 series, and then goes into detail about how the WebAuthn API works. I also look at how hardware tokens, such as the YubiKey 5 series, hide the complexity of WebAuthn from users. My goal is to demonstrate how easy it is to use a YubiKey to register and authenticate with a website without having to worry about the underlying WebAuthn API.

About the YubiKey 5 Series

The YubiKey 5 series supports a broad range of two-factor and multi-factor authentication protocols, including:

Challenge-response (HMAC-SHA1 and Yubico OTP).
Client to Authenticator Protocol (CTAP).
FIDO Universal 2nd-Factor authentication (U2F).
FIDO2.
Open Authorization, HMAC-Based One-Time Password (OATH-HOTP).
Open Authorization, Time-Based One-Time Password (OATH-TOTP).
OpenPGP.
Personal Identity Verification (PIV).
Web Authentication (WebAuthn).
Yubico One-Time Password (OTP).

In addition, the entire YubiKey 5 series (with the exception of the U2F/FIDO2-only Security Key model) now supports OpenPGP public key cryptography with RSA key sizes up to 4096 bits. This is a notable bump from the key sizes supported by some earlier models. Yubico's OpenPGP support also includes an additional slot for an OpenPGP authentication key for use within an SSH-compatible agent, such as GnuPG's gpg-agent.

Figure 1. YubiKey 5 Series

Go to Full Article

FOSS Project Spotlight: Bareos, a Cross-Network, Open-Source Backup Solution

Heike Jurzik and Maik Aussendorf — Fri, 17 May 2019 12:00:00 +0000

by Heike Jurzik a…

Bareos (Backup Archiving Recovery Open Sourced) is a cross-network, open-source backup solution that preserves, archives and recovers data from all major operating systems. The Bareos project started 2010 as a Bacula fork and is now being developed under the AGPLv3 license.

The client/server-based backup solution is actually a set of computer programs (Figure 1) that communicate over the network: the Bareos Director (BD), one or more Storage Dæmons (SD) and the File Dæmons (FD). Due to this modular design, Bareos is scalable—from single computer systems (where all components run on one machine) to large infrastructures with hundreds of computers (even in different geographies).

Figure 1. A Typical Bareos Setup: Director (with Database), File Dæmon(s), Storage Dæmon(s) and Backup Media

The director is the central control unit for all other dæmons. It manages the database (catalog), the connected clients, the file sets (they define which data Bareos should back up), the configuration of optional plugins, before and after jobs (programs to be executed before or after a backup job), the storage and media pool, schedules and the backup jobs. Bareos Director runs as a dæmon.

The catalog maintains a record of all backup jobs, saved files and volumes used. Current Bareos versions support PostgreSQL, MySQL and SQLite, with PostgreSQL being the preferred database back end.

The File Dæmon (FD) must be installed on every client machine. It is responsible for the backup as well as the restore process. The FD receives the director's instructions, executes them and transmits the data to the Bareos Storage Dæmon. Bareos offers pre-packed file dæmons for many popular operating systems, such as Linux, FreeBSD, AIX, HP-UX, Solaris, Windows and macOS. Like the director, the FD runs as a dæmon in the background.

The Storage Dæmon (SD) receives data from one or more File Dæmons (at the director's request). It stores the data (together with the file attributes) on the configured backup medium. Bareos supports various types of backup media, as shown in Figure 1, including disks, tape drives and even cloud storage solutions. During the restore process, the SD is responsible for sending the correct data back to the FD(s). The Storage Dæmon runs as a dæmon on the machine handling the backup device(s).

Go to Full Article

Signing Git Commits

Kyle Rankin — Thu, 16 May 2019 12:00:00 +0000

by Kyle Rankin

Protect your code commits from malicious changes by GPG-signing them.

Often when people talk about GPG, they focus on encryption—GPG's ability to protect a file or message so that only someone who has the appropriate private key can read it. Yet, one of the most important functions GPG offers is signing. Where encryption protects a file or message so that only the intended recipient can decrypt and read it, GPG signing proves that the message was sent by the sender (whomever has control over the private key used to sign) and has not been altered in any way from what the sender wrote.

Without GPG signing, you could receive encrypted email that only you could open, but you wouldn't be able to prove that it was from the sender. But, GPG signing has applications far beyond email. If you use a modern Linux distribution, it uses GPG signatures on all of its packages, so you can be sure that any software you install from the distribution hasn't been altered to add malicious code after it was packaged. Some distributions even GPG-sign their ISO install files as a stronger form of MD5sum or SHA256sum to verify not only that the large ISO downloaded correctly (MD5 or SHA256 can do that), but also that the particular ISO you are downloading from some random mirror is the same ISO that the distribution created. A mirror could change the file and generate new MD5sums, and you may not notice, but it couldn't generate valid GPG signatures, as that would require access to the distribution's signing key.

Why Sign Git Commits

As useful as signing packages and ISOs is, an even more important use of GPG signing is in signing Git commits. When you sign a Git commit, you can prove that the code you submitted came from you and wasn't altered while you were transferring it. You also can prove that you submitted the code and not someone else.

Being able to prove who wrote a snippet of code isn't so you know who to blame for bugs so the person can't squirm out of it. Signing Git commits is important because in this age of malicious code and back doors, it helps protect you from an attacker who might otherwise inject malicious code into your codebase. It also helps discourage untrustworthy developers from adding their own back doors to the code, because once it's discovered, the bad code will be traced to them.

How to Sign Git Commits

The simplest way to sign Git commits is by adding the -S option to the git commit command. First, figure out your GPG key ID with:

Go to Full Article

Password Manager Roundup

Shawn Powers — Fri, 03 May 2019 11:00:00 +0000

by Shawn Powers

If you can remember all of your passwords, they're not good passwords.

I used to teach people how to create "good" passwords. Those passwords needed to be lengthy, hard to guess and easy to remember. There were lots of tricks to make your passwords better, and for years, that was enough.

That's not enough anymore.

It seems that another data breach happens almost daily, exposing sensitive information for millions of users, which means you need to have separate, secure passwords for each site and service you use. If you use the same password for any two sites, you're making yourself vulnerable if any single database gets compromised.

There's a much bigger conversation to be had regarding the best way to protect data. Is the "password" outdated? Should we have something better by now? Granted, there is two-factor authentication, which is a great way to help increase the security on accounts. But although passwords remain the main method for protecting accounts and data, there needs to be a better way to handle them—that's where password managers come into play.

The Best Password Manager

No, I'm not burying the lede by skipping all the reviews. As Doc Searls, Katherine Druckman and myself discussed in Episode 8 of the Linux Journal Podcast, the best password manager is the one you use. It may seem like a cheesy thing to say, but it's a powerful truth. If it's more complicated to use a password manager than it is to re-use the same set of passwords on multiple sites, many people will just choose the easy way.

Sure, some people are geeky enough to use a password manager at any cost. They understand the value of privacy, understand security, and they take their data very seriously. But for the vast majority of people, the path of least resistance is the way to go. Heck, I'm guilty of that myself in many cases. I have a Keurig coffee machine, not because the coffee is better, but because it's more convenient. If you've ever eaten a Hot Pocket instead of cooking a healthy meal, you can understand the mindset that causes people to make poor password choices. If the goal is having smart passwords, it needs to be easier to use smart passwords than to type "password123" everywhere.

Go to Full Article