Jupiter Broadcasting

Code and Community | BSD Now 234

chris

RSS Feeds:

MP3 Feed | iTunes Feed | HD Vid Feed | HD Torrent Feed

Become a supporter on Patreon:

– Show Notes: –

Headlines

Google Summer of Code 2018

You can join #freebsd-soc on the efnet IRC network to chat with FreeBSD developers interested in mentoring student proposals and projects, past FreeBSD/GSoC students, and other students applying to FreeBSD/GSoC this year.

You can get a stipend (paid for by Google) and spend a few months getting to know and improving the insides of NetBSD or pkgsrc.

The schedule is:
12-27 March Applying
23 April Find out if you were accepted
14 May – 22 August Do the project!

We have some suggestions for suitable projects:
– ARM EFI bootloader
– Using libFuzzer on base tools
– Refactoring ALTQ (QoS implementation) and integrating with NPF
– Testsuite for libcurses
– Improve pkgin

Other suggestions and details are at:
https://wiki.netbsd.org/projects/gsoc/

These projects are suggestions; you can come up with your own. Suggestions for other suitable projects are welcome.

Feel free to contact, or chat around on IRC: irc.freenode.org #netbsd #netbsd-code #pkgsrc

If you have questions you can contact the devs on IRC: irc.freenode.org #haiku

FreeBSD Jails with iocage

FreeBSD jails allow users to run multiple, isolated instances of FreeBSD on a single server. Iocage simplifies the management of FreeBSD Jails. Following this tutorial, the jails will be configured to bind to an IP address on the jail host’s internal network, and the host OS will pass traffic from the external network to the jail.

The jails will be managed with Iocage. Iocage uses ZFS properties to store configuration data for each jail, so a ZFS file system is required.

PF is full featured firewall, and can do more than just pass traffic to an internal network. Refer to the PF documentation for additional configuration options.

sysrc cloned_interfaces+="lo1"
sysrc ifconfig_lo1="inet 192.0.2.1/24"
sysrc pf_enable="YES"


# Variables
# ext_if should be set to the hosts external NIC

ext_if = "vtnet0"
jail_if = "lo1"
jail_net = $jail_if:network

# NAT allows the jails to access the external network#

nat on $ext_if from $jail_net to any -> ($ext_if)

# Redirect traffic on port 80 to the web server jail

# Add similar rules for additional jails

rdr pass on $ext_if inet proto tcp to port 80 -> 192.0.2.10

The best way to use ZFS on a VPS is to attach block storage as a new disk.
If block storage is not available, you can optionally use a file as the ZFS device.

sysrc zfs_enable="YES"
service zfs start

List the available disks.
If you are using a VPS, the block store will probably be the second disk.

geom disk list

zpool create jailstore /dev/vtbd1

dd if=/dev/zero of=/zfsfile bs=1M count=4096

zpool create jailstore /zfsfile

pkg install py36-iocage

Skip to “Using iocage”

Smaller servers may not have enough RAM to build iocage. If needed, create a swap file and reboot.

dd if=/dev/zero of=/swapfile bs=1M count=1024
echo 'swapfile="/swapfile"' >> /etc/rc.conf
reboot

pkg install subversion python36 git-lite libgit2 py36-pip

svn checkout https://svn.freebsd.org/base/releng/11.1 /usr/src


portsnap fetch
portsnap extract

cd /usr/ports/sysutils/iocage/
make install


iocage activate jailstore
iocage fetch

iocage create -n www ip4_addr="lo1|192.0.2.10/24" -r 11.1-RELEASE
iocage start www
iocage console www

Once you have a shell inside the jail, install and start Apache.

pkg install apache24
sysrc apache24_enable="yes"
service apache24 start

Port 80 on the jail will now be accessible on the hosts IP address.

Additional jails can be installed using the example above.

iXsystems

New FreeBSD Code of Conduct

The FreeBSD Project is inclusive. We want the FreeBSD Project to be a venue where people of all backgrounds can work together to make the best operating system, built by a strong community. These values extend beyond just development to all aspects of the Project. All those given recognition as members of the Project in whatever form are seen as ambassadors of the Project.

Diversity is a huge strength and is critical to the long term success of the Project. To that end we have a few ground rules that we ask people to adhere to. This code applies equally to everyone representing the FreeBSD Project in any way, from new members, to committers, to the core team itself. These rules are intended to ensure a safe, harassment-free environment for all and to ensure that everyone feels welcome both working within, and interacting with, the Project.

This document is not an exhaustive list of things that you should not do. Rather, consider it a guide to make it easier to enrich all of us and the technical communities in which we participate.

This code of conduct applies to all spaces used by the FreeBSD Project, including our mailing lists, IRC channels, and social media, both online and off. Anyone who is found to violate this code of conduct may be sanctioned or expelled from FreeBSD Project controlled spaces at the discretion of the FreeBSD Code of Conduct Committee.

Some FreeBSD Project spaces may have additional rules in place, which will be made clearly available to participants. Participants are responsible for knowing and abiding by these rules.

Interview – Benno Rice – benno@freebsd.org / @jeamland

News Roundup

libhijack in PoC||GTFO 0x17!

In the land of red devils known as Beasties exists a system devoid of meaningful exploit mitigations. As we explore this vast land of opportunity, we will meet our ELFish friends, [p]tracing their very moves in order to hijack them. Since unprivileged process debugging is
enabled by default on FreeBSD, we can abuse PTrace to create anonymous memory mappings, inject code into them, and overwrite PLT/GOT entries. We will revive a tool called libhijack to make our nefarious activities of hijacking ELFs via PTrace relatively easy.

Nothing presented here is technically new. However, this type of work has not been documented in this much detail, tying it all into one cohesive work. In Phrack 56, Silvio Cesare taught us ELF research enthusiasts how to hook the PLT/GOT. The Phrack 59 article on Runtime Process Infection briefly introduces the concept of injecting shared objects by injecting shellcode via PTrace that calls dlopen(). No other piece of research, however, has discovered the joys of forcing the application to create anonymous memory mappings in which to inject
Code.

This is only part one of a series of planned articles that will follow libhijack’s development. The end goal is to be able to anonymously inject shared objects. The libhijack project is maintained by the SoldierX community.

All prior work injects code into the stack, the heap, or existing executable code. All three methods create issues on today’s systems. On amd64 and arm64, the two architectures libhijack cares about, the stack is non-executable by default. jemalloc, the heap implementation
on FreeBSD, creates non-executable mappings. Obviously overwriting existing executable code destroys a part of the executable image.

FreeBSD provides a nifty API for inspecting the entire virtual memory space of an application. The results returned from the API tells us the protection flags (readable, writable, executable) of each mapping. If FreeBSD provides such a rich API, why would we need to parse the ELF headers?

PLT/GOT hijacking requires parsing ELF headers. One would not be able to find the PLT/GOT without iterating through the Process Headers to find the Dynamic Headers, eventually ending up with the DT_PLTGOT entry.

With FreeBSD’s libprocstat API, we don’t have a need for parsing ELF headers until we get to the PLT/GOT stage, but doing so early makes it easier for the attacker using libhijack

Writing devious code in assembly is cumbersome. Assembly doesn’t scale well to multiple architectures. Instead, we would like to write our devious code in C, compiling to a shared object that gets injected anonymously. This requires writing a remote RTLD within libhijack and
is in progress. Writing a remote RTLD will take a while as doing so is not an easy task.

Additionally, creation of a general-purpose helper library that gets injected would be helpful. It could aid in PLT/GOT redirection attacks, possibly storing the addresses of functions we’ve previously hijacked. This work is dependent on the remote RTLD.

libhijack currently lacks documentation. Once the ABI and API stabilize, formal documentation will be written.

Using libhijack, we can easily create anonymous memory mappings, inject into them arbitrary code, and hijack the PLT/GOT on FreeBSD. On HardenedBSD, a hardened derivative of FreeBSD, libhijack is fully mitigated through PaX NOEXEC.

We’ve demonstrated that wrapper-style Capsicum is ineffective on FreeBSD. Through the use of libhijack, we emulate a control flow hijack in which the application is forced to call sandbox_open and fdlopen on the resulting file descriptor.

Further work to support anonymous injection of full shared objects, along with their dependencies, will be supported in the future. Imagine injecting libpcap into Apache to sniff traffic whenever “GET /pcap” is sent.

In order to prevent abuse of PTrace, FreeBSD should set the security.bsd.unprivileged_proc_debug to 0 by default. In order to prevent process manipulation, FreeBSD should implement PaX NOEXEC.

Introduction to POSIX shell

What the heck is the POSIX shell anyway? Well, the POSIX (the Portable Operating System Interface) shell is the standard Unix shell – standard meaning it was formally defined and shipped in a published standard. This makes shell scripts written for it portable, something no other shell can lay claim to. The POSIX shell is basically a formalized version of the venerable Bourne shell, and on your system it lives at /bin/sh, unless you’re one of the unlucky masses for whom this is a symlink to bash.

The “Bourne Again shell”, aka bash, is not standardized. Its grammar, features, and behavior aren’t formally written up anywhere, and only one implementation of bash exists. Without a standard, bash is defined by its implementation. POSIX shell, on the other hand, has many competing implementations on many different operating systems – all of which are compatible with each other because they conform to the standard.

Any shell that utilizes features specific to Bash are not portable, which means you cannot take them with you to any other system. Many Linux-based systems do not use Bash or GNU coreutils. Outside of Linux, pretty much everyone but Hurd does not ship GNU tools, including bash1. On any of these systems, scripts using “bashisms” will not work.

This is bad if your users wish to utilize your software anywhere other than GNU/Linux. If your build tooling utilizes bashisms, your software will not build on anything but GNU/Linux. If you ship runtime scripts that use bashisms, your software will not run on anything but GNU/Linux. The case for sticking to POSIX shell in shipping software is compelling, but I argue that you should stick to POSIX shell for your personal scripts, too. You might not care now, but when you feel like flirting with other Unicies you’ll thank me when all of your scripts work.

One place where POSIX shell does not shine is for interactive use – a place where I think bash sucks, too. Any shell you want to use for your day-to-day command line work is okay in my book. I use fish. Use whatever you like interactively, but stick to POSIX sh for your scripts.

At the top of your scripts, put #!/bin/sh. You don’t have to worry about using env here like you might have been trained to do with bash: /bin/sh is the standardized location for the POSIX shell, and any standards-conforming system will either put it there or make your script work anyway.

The next step is to avoid bashisms. There are many, but here are a few that might trip you up:

The easiest way to learn about POSIX shell is to read the standard – it’s not too dry and shorter than you think.

The last step to writing portable scripts is to use portable tools. Your system may have GNU coreutils installed, which provides tools like grep and cut. Unfortunately, GNU has extended these tools with its own non-portable flags and tools. It’s important that you avoid these.

One dead giveaway of a non-portable flag is long flags, e.g. grep –file=FILE as opposed to grep -f. The POSIX standard only defines the getopt function – not the proprietary GNU getopt_long function that’s used to interpret long options. As a result, no long flags are standardized. You might worry that this will make your scripts difficult to understand, but I think that on the whole it will not. Shell scripts are already pretty alien and require some knowledge to understand. Is knowledge of what the magic word grep means much different from knowledge of what grep -E means?

I also like that short flags allow you to make more concise command lines. Which is better: ps –all –format=user –without-tty, or ps -aux? If you are inclined to think the former, do you also prefer function(a, b, c) { return a + b + c; } over (a, b, c) => a + b + c? Conciseness matters, and POSIX shell supports comments if necessary!

A good reference for learning about standardized commands is, once again, the standard. From this page, search for the command you want, or navigate through “Shell & Utilities” -> “Utilities” for a list. If you have man-pages installed, you will also find POSIX man pages installed on your system with the p postfix, such as man 1p grep. Note: at the time of writing, the POSIX man pages do not use dashes if your locale is UTF-8, which makes searching for flags with / difficult. Use env LC_ALL=POSIX man 1p grep if you need to search for flags, and I’ll speak to the maintainer of man-pages about this.

FreeBSD Broadcom Wi-Fi Improvements

Since 2015, I’ve been working on improving FreeBSD support for Broadcom Wi-Fi devices and SoCs, including authoring the bhnd(4) driver family, which provides a unified bus and driver programming interface for these devices.

First committed in early 2016, bhnd(4) allowed us to quickly bring up FreeBSD/MIPS on Broadcom SoCs, but it has taken much longer to implement the full set of features required to support modern Broadcom SoftMAC Wi-Fi hardware.

Thanks to the generosity of the FreeBSD Foundation, I’ve recently finished implementing the necessary improvements to the bhnd(4) driver family. With these changes in place, I was finally able to port the existing bwn(4) Broadcom SoftMAC Wi-Fi driver to the bhnd(4) bus, and implement initial support for the BCM43224 and BCM43225 chipsets, with additional hardware support to be forthcoming.

Now that my efforts on FreeBSD/Broadcom Wi-Fi support have progressed far enough to be generally useful, I wanted to take some time to provide a brief overview of Broadcom’s Wi-Fi hardware, and explain how my work provides a foundation for further FreeBSD Broadcom Wi-Fi/SoC improvements.

Broadcom’s Wi-Fi devices are members of the Broadcom Home Networking Division (BHND) device family; other BHND devices include MIPS/ARM SoCs (including Wi-Fi SoCs commonly found in consumer access points), as well as a large variety of related networking hardware.

When BHND hardware is used in a PCI Wi-Fi card, or a SDIO Wi-Fi module, the device’s dual-mode peripheral controller is configured to operate as an endpoint device on the host’s peripheral bus, bridging access to the SoC hardware:

The host is generally expected to provide drivers for the IP cores found on the SoC backplane; since these cores are found in both BHND SoCs and BHND Wi-Fi devices, it is advantageous to share driver and platform code between the two targets.

By porting bwn(4) to bhnd(4), we are now able to support existing BCMA devices with MAC/PHY/Radio combinations readily supported by bwn(4), as was the case with the BCM43224 and BCM43225 chipsets. This also opens the door to porting additional PHY support from Broadcom’s ISC-licensed Linux drivers, and will allow us to bring up bwn(4) on Broadcom WiSoCs supported by FreeBSD/MIPS.

Monitor OpenSMTPD using Logstash and Grafana

Logs are usefull. Graphs are sexy. Here’s a way to get a view on what happens to your OpenSMTPD traffic, using Web v2.0 tools ; namely Logstash & Grafana.
For those who would not be aware of those tools, logstash is some kind of log-parser that can eat syslog formatted logs and write them into elasticsearch ; in “document” format. Grafana is a Web frontend that can dig into various databases and render graphics from requests.
I won’t go into the whole “how to install” process here. Installation is quite straight forward and online documentation is quite clear.

OpenSMTPD deals with emails and logs its activity via Syslog.
Syslog is configured to send the logs to Logstash.
Logstash has a set of rules configured to transform the text-oriented information into searchable document-oriented data. The transformed data is stored into Elasticsearch.
Elasticsearch provides Web API to search and find stuff.
Grafana connects to ELS to get data and draw the graphs.

Beastie Bits

Feedback/Questions