Security Archives - FreeBSDNews.com

Design of a Trust System for FreeBSD

May 26, 2017 By Cao Leave a Comment

User Eric McCorkle discusses some security aspects of FreeBSD, notably signatures (executables, library, kernel) in his latest blog. This article is broken down in sections such as signed elf binaries, portable verification library, key management, etc. Read the whole thing at the link below.

About a month ago, I started a discussion on freebsd-hackers and freebsd-security about a system for signed executables, with a focus on signed kernels and kernel modules. This is part of a larger agenda of mine to equip FreeBSD with OS-level tamper resistance features.

While the initial use of this is for signing the kernel and its modules, and checking signatures during the loader process as well as at runtime when kernel modules are loaded. However, it is desirable to build a system that is capable of growing in likely directions, such as executable and library signing.

This article details the current state of the design of this system.

Desiderata

I originally outlined a number of goals for this system:

Be able to check for a correct cryptographic signature for any kernel or modules loaded at boot time for some platforms (EFI at a minimum)
Be able to check for a correct cryptographic signature for any kernel module loaded during normal operations (whether or not to do this could be controlled by a sysctl, securelevel, or some similar mechanism) ….

Original post: https://ericmccorkleblog.wordpress.com/2017/05/19/design-of-a-trust-system-for-freebsd/

The True Value of Randomness & Deeper Exploration in (Free|Hardened)BSD Entropy

February 3, 2017 By Cao Leave a Comment

This blog series by user W. Dean Freeman discusses some security aspects of HardenedBSD, along with an Entropy Assessment of FreeBSD. The author runs various tests using DTrace and documents his findings across 2 different blogs, and more to come in the future. Check out the blog links for the full and detailed report.

The True Value of Randomness: Initial Results in Hardened/FreeBSD Entropy Assessment (Part 1 of Series)

First, touching back on some background: Currently, I am employed by Acumen Security, LLC as a Lead Security Engineer where I work on Common Criteria and FIPS consulting and evaluation testing. Most of this (especially the FIPS 140 stuff) is basically being the crypto police — verifying the correct implementation and operation of cryptographic algorithms and modules, correct implementation of encrypted communications channels, etc.

In order for a product to be accepted into evaluation these days, the product vendor and lab must first submit an Entropy Assessment Report. Essentially, this is proving that there is enough raw randomness being fed into the crypto system from the start, because if you have week or predictable initial entropy, the strength of the entire rest of the crypto system is compromised

Original article: https://www.weaponizedawesome.com/blog/?p=154

Deeper Exploration in (Free|Hardened)BSD Entropy (Part 2 of series)

So, the other day I posted some background and initial findings from a side project in attempting to measure entropy in FreeBSD and HardenedBSD systems. Rather than instrumenting the kernel with printf(9) or log(9) calls, I decided that I wanted to take the opportunity to start digging with with DTrace.

The first blog post attracted a little bit of attention, and I got into a fairly long conversation on Twitter with John-Mark Gurney that let me know that I was on the right track, but needed to get a little bit further in to really, effectively count what was being fed in.

Original article: https://www.weaponizedawesome.com/blog/?p=173

[FreeBSD-Announce] FreeBSD Core statement on recent freebsd-update and related vulnerabilities

August 12, 2016 By Cao Leave a Comment

The FreeBSD Core & Security teams have made a recent announcement concerning freebsd-update and portsnap vulnerabilities. See the full the message from the mailing list which should address any concerns among the community.

Dear FreeBSD Community:

The FreeBSD Core team and FreeBSD Security team would like to update the community on the reports of security vulnerabilities in freebsd-update, portsnap, libarchive, and bspatch.

We understand the severity of this issue, and are actively working to resolve the issues and improve the security of FreeBSD.

A recent post[1] to the freebsd-security@ list raised a number of questions[2] and we would like to address those.

1. Since there are known vulnerabilities in freebsd-update and portsnap, why has there been no notification to the community from secteam@?

As a general rule, the FreeBSD Security Officer does not announce vulnerabilities for which there is no released patch. We are reviewing this policy for cases where a proof-of-concept or working exploit is already public.

2. Why was there no mention of the fact that running freebsd-update to install the fix for the bspatch advisory [SA-16:25] may actually expose users to the vulnerability?

To be exposed, a user would need to be under an active Man-In-The-Middle attack when fetching patches. The Security Advisory did not contain information on the theoretical implications of the vulnerability. A more explicit paragraph in the 'Impact' statement may have been warranted. As always, instructions on how to compile the patched bspatch manually rather than using freebsd-update were provided as part of the advisory.

3. The patch included in SA-16:25 is incomplete, and may still permit heap corruption. The patch included in the document dump is more complete. Why only a partial fix?

Original announcement: https://lists.freebsd.org/pipermail/freebsd-announce/2016-August/001739.html

[Blog] FreeBSD OS-Level Tamper-Resilience

July 25, 2016 By Cao Leave a Comment

User Eric McCorkle outlines his plan for a tamper-resilient FreeBSD system. Combined with GELI disk encryption, McCorkle goes over his thoughts on secure boot, secure suspend/resume, data protection, and more.

UI’ve posted about my work on EFI GELI support. This project is actually the first step in a larger series of changes that I’ve been sketching out since April. The goal of the larger effort is to implement tamper-resilience features at the OS level for FreeBSD. The full-disk encryption capabilities provided by GELI boot support represent the first step in this process.
OS-Level Tamper-Resilience

Before I talk about the work I’m planning to do, it’s worth discussing the goals and the rationale for them. One of the keys to effective security is an accurate and effective threat model; another is identifying the scope of the security controls to be put in place. This kind of thinking is important for this project in particular, where it’s easy to conflate threats stemming from vulnerable or malicious hardware with vulnerabilities at the OS level.

Original post: https://ericmccorkleblog.wordpress.com/2016/07/17/freebsd-os-level-tamper-resilience/

The state of LibreSSL in FreeBSD

July 8, 2016 By Cao Leave a Comment

This article by user Attila Györffy discusses the current direction of LibreSSL in FreeBSD. LibreSSL, forked from OpenSSL after the known Heartbleed vulnerability, is an open source implementation of the Secure Sockets Layer (SSL) protocol.

libresslfreebsd

As part of my ongoing effort to evaluate FreeBSD as a server OS I took the time to see what it takes to replace OpenSSL with LibreSSL for increased system security.

I’m sure most of you are familiar with the beast that OpenSSL is and I wanted to see whether completely replacing OpenSSL with LibreSSL was a viable option.

Replacing OpenSSL with LibreSSL in FreeBSD 10.3 base

Thanks to Bernard Spil and the HardenedBSD team’s ongoing efforts to increase security in the FreeBSD operating system we are now at a point where incorporating LibreSSL into the FreeBSD base system is a relatively straight forward option.

Original article: https://attilagyorffy.com/2016/07/02/the-state-of-libressl-in-freebsd/

Hacker News discussion: https://news.ycombinator.com/item?id=12025638

/r/hackernews discussion: https://www.reddit.com/r/hackernews/comments/4r3c11/the_state_of_libressl_in_freebsd/t1_d4xxw63

[How-To] LetsEncrypt on FreeBSD

July 1, 2016 By Cao Leave a Comment

This short tutorial by user LK shows us how to get LetEncrypt setup on FreeBSD. LetsEncrypt is a free, automated, and open certificate authority (CA) which provides users with DV certificates for SSL, enabling secure transfer of information through HTTPS.

FreeBSD

Install Let’s Encrypt client from port with the following command:
cd /usr/ports/security/py-letsencrypt && make install clean
Install Let’s Encrypt client from port with the following command:
pkg install py27-letsencrypt

Original post: https://techjourney.net/how-to-install-lets-encrypt-in-centos-rhel-fedora-freebsd-openbsd-ubuntu-linux/?utm_source=Google%2B&utm_medium=Tech+Journey&utm_campaign=Social%2BSharing%2Bby%2BTech+Journey

[Blog] Analysis of SETFKEY FreeBSD kernel, compatibility layers, vulnerabilities by CTurt

June 3, 2016 By Cao Leave a Comment

FreeBSD security researcher CTurt, known for his recent work in the PS4 kernel exploit, outlines a recent FreeBSD kernel vulnerability found in iotcl handlers. In addition, check out his article on vulnerabilities in FreeBSD compatibility layers.

Every FreeBSD keyboard driver exposes its own ioctl interface to allow it to be configured from userland (through the kbdcontrol utility for example). Typically, these ioctl handlers will implement any specific commands for the hardware, such as enabling or disabling LEDs, and will delegate the rest of the commands to a common handler, called genkbd_commonioctl.

I discovered a vulnerability in this common handler, which has been present since the driver’s introduction in 1999.

Due to a poor default sysctl variable, this bug can be triggered by an unprivileged user, so long as at least one keyboard driver is running (by default the atkbd driver is used), making its impact critical.

I decided to report this bug to the FreeBSD Security Team on April 22, 2016, the day after I had discovered it, and was able to exploit it about a week later. It has been assigned CVE-2016-1886 and Security Advisory 16:18.

In this article I will provide an explanation of the bug, and some of the methods which I considered for exploitation, including the one I had success with: using the corrupted len member of a keytab to trigger a powerful two way heap and stack overflow.

Original post: http://cturt.github.io/SETFKEY.html

Analysis of stack disclosure vulnerabilities in FreeBSD compatibility layers

Arguably one of FreeBSD’s most renowned features is its compatibility layers. In particular, FreeBSD provides compatibility layers for 32-bit Linux binaries and for legacy 4.3BSD software. These are usually enabled by building a custom kernel with the COMPAT_LINUX32 and COMPAT_43 configuration options, however the Linux compatibility layer is also implemented as a separate kernel module, which can be loaded at runtime instead (kldload linux).

Original post: http://cturt.github.io/compat-info-leaks.html

FreeBSD sysarch system-crashing bug

March 25, 2016 By Cao Leave a Comment

For those who have not seen it, this a recent security advisory letting users know to update to the latest stable FreeBSD.

A programming blunder involving integer signedness can be exploited by a logged-in user to crash a system. With the right parameters, you can trick the kernel into clearing too much of its heap memory with zeros via the sysarch system call, which will eventually lead to a kernel panic.
II.  Problem Description

A special combination of sysarch(2) arguments, specify a request to
uninstall a set of descriptors from the LDT.  The start descriptor
is cleared and the number of descriptors are provided.  Due to invalid
use of a signed intermediate value in the bounds checking during argument
validity verification, unbound zero'ing of the process LDT and adjacent
memory can be initiated from usermode.

III. Impact

This vulnerability could cause the kernel to panic. In addition it is
possible to perform a local Denial of Service against the system by
unprivileged processes.

Original article: http://www.theregister.co.uk/2016/03/18/freebsd_bug_patched/

Security Advisory: https://www.freebsd.org/security/advisories/FreeBSD-SA-16:15.sysarch.asc

FreeBSD, Variants Not Affected by Recent GNU Bug by Larry

February 26, 2016 By Cao Leave a Comment

larrybsdguy Larry the BSD Guy reports that the recent vulnerability in UNIX systems does not affect the FreeBSD operating system or any of its variants. Follow the link below for the full blog.

The glibc security vulnerability that Linux developers have been scrambling to patch does not affect *BSD.

Much has been made about a vulnerability in a function in the GNU C Library. And searching far and wide over the Internet, there was little — actually nothing — I could find regarding how this affected BSD variants.

However, you can rest easy, BSDers: Not our circus, not our monkeys.

Dag-Erling Smørgrav, a FreeBSD developer since 1998 and a former FreeBSD Security Officer, writes in his blog that “neither FreeBSD itself nor native FreeBSD applications are affected.”

Full blog: http://fossforce.com/2016/02/freebsd-variants-not-affected-recent-gnu-bug/

How-To: LetsEncrypt on FreeBSD

February 19, 2016 By Cao Leave a Comment

Thanks to this tutorial by user BernardSpil, we can get LetsEncrypt running on FreeBSD. Follow the link below for the full instructions.

Started this as I felt that the standard LetsEncrypt client was way too fat and had too many dependencies to be allowed to run as root. Even though this is all pretty basic stuff, I decided to document it here.

Guide changed to use the security/letsencrypt.sh port

The original guide can be found in the lower half of this document.

Some notes on the configuration of my setup

All services accessible from the internet run in jails (all jails reside in /usr/jails by default on FreeBSD)

I use LibreSSL (LibreSSL port)

I use The Z Shell (zsh port)

Things that don’t need to run as root will be running as an unprivileged user. I will use the user _letsencrypt with group _letsencrypt as the unprivileged user that will perform the certificate renewal process. Deployment of the keys and certificates will have to be executed with a privileged user, this guide uses root.

Install Letsencrypt.sh

The port is available in the ports tree. Install it using the official pkg repository using….

Full tutorial: https://wiki.freebsd.org/BernardSpil/LetsEncrypt