Skip to main content.

Episode 227: The long core dump

2018-01-03

Direct Download:

This episode was brought to you by

iXsystems - Enterprise Servers and Storage for Open SourceDigitalOcean - Simple Cloud Hosting, Built for DevelopersTarsnap - Online Backups for the Truly Paranoid


Headlines

NetBSD 7.1.1 released

  • The NetBSD Project is pleased to announce NetBSD 7.1.1, the first security/critical update of the NetBSD 7.1 release branch. It represents a selected subset of fixes deemed important for security or stability reasons.
  • Complete source and binaries for NetBSD 7.1.1 are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, and other services may be found at https://www.NetBSD.org/mirrors/. We encourage users who wish to install via ISO or USB disk images to download via BitTorrent by using the torrent files supplied in the images area. A list of hashes for the NetBSD 7.1.1 distribution has been signed with the well-connected PGP key for the NetBSD Security Officer: https://ftp.NetBSD.org/pub/NetBSD/security/hashes/NetBSD-7.1.1_hashes.asc
  • NetBSD is free. All of the code is under non-restrictive licenses, and may be used without paying royalties to anyone. Free support services are available via our mailing lists and website. Commercial support is available from a variety of sources. More extensive information on NetBSD is available from our website:
  • NetBSD website +Changes Between 7.1 and 7.1.1 Below is an abbreviated list of changes in this release. The complete list can be found in the CHANGES-7.1.1 file in the top level directory of the NetBSD 7.1.1 release tree.
    • Security Advisory Fixes The following security advisories were fixed:
    • NetBSD-SA2017-004 buffer overflow via cmap for 4 graphics drivers.
    • NetBSD-SA2017-005 x86: vulnerabilities in context handling.
    • NetBSD-SA2017-006 Vnode reference leak in the openat system call.
    • NetBSD-SA2018-001 Several vulnerabilities in context handling
    • NetBSD-SA2018-002 Local DoS in virecover
    • Note: Advisories prior to NetBSD-SA2017-004 do not affect NetBSD 7.1.1.
    • Userland changes
    • dhcrelay(8): Fix bug that prevented proper operation when run in the background.
    • Heimdal: Update to 7.1. Fix CVE-2017-11103.
    • mtree(8): Don't modify strings stored in hash, otherwise filling up of directory hierarchy stops if the same hash value occurs in directory and leaf.
    • ping(8): Fix cksum calculation for clearing the cached route.
    • resize_ffs(8): Fix numerous overflow errors which can lead to superblock corruption on large filesystems.
    • rtadvd(8): Fix the default value of rltime. PR bin/51994.
    • Update BIND to 9.10.5-P2.
    • Update expat to 2.2.1.
    • Update ntp to 4.2.8p10.
    • Update root.cache to 2017102400.
    • Update tzdata to 2017c.
    • vi(1): Don't garble display when when resizing nvi in xterm.
  • wpa_supplicant/hostapd: Update to 2.6.
  • Apply fixes for CVEs 2017-13077 through 2017-13082 and CVEs 2017-13086 through 2017-13088.
  • X: Apply fixes for CVEs 2017-12176 through 2017-12187, 2017-10971, 2017-10972, 2017-13722, 2017-13720, 2017-16611, and 2017-16612.

Dumping a PS4 Kernel in "Only" 6 Days

What if a secure device had an attacker-viewable crashdump format? What if that same device allowed putting arbitrary memory into the crashdump? Amazingly, the ps4 tempted fate by supporting both of these features! Let’s see how that turned out… + Crashdumps on PS4 + The crash handling infrastructure of the ps4 kernel is interesting for 2 main reasons: + It is ps4-specific code (likely to be buggy) + If the crashdump can be decoded, we will gain very useful info for finding bugs and creating reliable exploits + On a normal FreeBSD system, a kernel panic will create a dump by calling kernreboot with the RBDUMP flag. This then leads to doadump being called, which will dump a rather tiny amount of information about the kernel image itself to some storage device. + On ps4, the replacement for doadump is mdbgrundump, which can be called from panic or directly from trapfatal. The amount of information stored into the dump is gigantic by comparison - kernel state for all process, thread, and vm objects are included, along with some metadata about loaded libraries. Other obvious changes from the vanilla FreeBSD method are that the mdbgrundump encodes data recorded into the dump on a field-by-field basis and additionally encrypts the resulting buffer before finally storing it to disk. + Dumping Anything + Let’s zoom in to a special part of mdbgrundump - where it iterates over all process’ threads and tries to dump some pthread state: + dumpstate is a temporary buffer which will eventually make it into the crashdump. To summarize, sysdumpinternalcallreaduser can be made to function as a read-anywhere oracle. This is because fsbase will point into our (owned) webkit process’ usermode address space. Thus, even without changing the actual fsbase value, we may freely change the value of tcb_thread, which is stored at fsbase + 0x10. + Further, sysdumpinternalcall_readuser will happily read from a kernel address and put the result into the dump. + We can now put any kernel location into the dump, but we still need to decrypt and decode it… + Aside from that, there’s also the issue that we may only add 0x10 bytes per thread in this manner… + Further reading: + Crashdump Crypto + Crashdump Decoding + Crashdump Automation + Triggering the Vulnerability + The Fix (Kind of…) + Fin + Appendix + Crashdump Decryptor + NXDP Decoder


BSDTW 2017 Conference Recap: Li-Wen Hsu

  • BSDTW 2017 Conference Recap: Li-Wen Hsu
  • 12/28/2017 > Last month, we held BSDTW 2017 on November 11-12th, 2017 in Taipei, Taiwan. It was the second largest BSD conference in Taiwan and the first one in this decade. In 2004, the first AsiaBSDCon was also held in Taipei. Then all of the following AsiaBSDCon conferences were held in Tokyo, Japan. (AsiaBSDCon 2018 will be in Tokyo again next year, please submit your talk proposal by December 31th 2017, and attend the conference on March 8th-11th) > We wanted to start small with the first BSDTW because we were not sure how much sponsorship or how many volunteers we might have. BSDTW 2017 was a single track, two-day conference with 11 selected 50 minute presentations and 1 WIP/lightning talk session consisting of 8 short talks. I do regret that we did not have any local presenters this year. It is also a similar problem at AsiaBSDCon. Unsurprisingly, as with AsiaBSDcon, the travel reimbursement took up a large part of the whole conference budget. We do have many good people that work in Asia, but we still need to encourage people to present their work more. > We had over 130 registered attendees, with 30% of them coming from outside of Taiwan. To our knowledge, in recent years, this is the only open source conference in Taiwan to be held entirely in English, and to have such a large portion of international attendees. This is also the first open source conference in Taiwan to focus entirely on operating systems. The attendees included students, professors, engineers or CTOs, and CEOs from technology companies. This is also the first time that GroffTheBSDGoat visited Taiwan! We were surprised that after the silence for so many years, there are still so many people that use and love BSD near us. We saw many old friends, who had “disappeared” for a long time, came back, and were glad to meet many new friends at the conference. I am really happy that this conference was able to bring together these people, from local and abroad. After attending BSD conferences around the world for many years, I feel that the friendship between BSD users is the most important thing in the BSD community, and one of the main reasons people stay. It has been my pleasure to bring this community back to my friends in my homeland. > After the two-day event, I truly understand that bootstrapping a new conference is a very hard job. One with many aspects that you don’t even imagine until you’re really in the process of planning an event. I now have an even greater respect for all of the conference organizers and realize that we need to have more people help them, to keep these conferences continue to get better and better. Plus, there will always be room for a new conference! > Thanks to the FreeBSD Foundation for being the biggest sponsor of BSDTW 2017 and always being the strongest backend of our community. We are excited about the many local companies and organizations that helped us whether with people, materials or financially. We even had 21 personal sponsors, more than two times the number of other big open source conferences in Taiwan. > As I said in the closing session, I’m not sure if there will be 2nd BSDTW next year. It still depends on the amount of sponsorship and number of volunteers. However, we will definitely hold more smaller meetups in the next year to keep building up the local BSD community. > Finally, in the beginning of this month, we had a “post-conference media workshop” for organizing the media files we collected in the BSDTW 2017. Here are the review article in Traditional Chinese and the photos: https://medium.com/@bsdtw/bsdtw-2017-總回顧-a402788daede && https://www.flickr.com/photos/bsdtw/albums/72157689410035911

News Roundup

Running FreeBSD on a Lenovo T470s

  • Running FreeBSD on the Lenovo T470s ThinkPad > Installing FreeBSD on this machine was super easy. As I couldn't find a comprehensive/encouraging how-to about installing FreeBSD on a recent ThinkPad, I just wrote up the one below. It includes details about my personal setup, which are not required to run FreeBSD on this model, but which are more to my own taste. I still think this can be a quite useful inspiration for others who want to run their own customized configurations.
  • Specs > The system I use has these specifications:
  • Type: 20JS-001EGE
  • CPU: Intel Core i7-6600U, 2x 2.60GHz
  • RAM: 20GB DDR4
  • SSD: 512GB NVMe
  • Graphics: Intel HD Graphics 520 (IGP), 1x HDMI 1.4
  • Display: 14", 1920x1080, non-glare, IPS
  • Ports: 3x USB-A 3.0, 1x Thunderbolt 3, 1x Gb LAN
  • Wireless: WLAN 802.11a/b/g/n/ac, Bluetooth 4.1, LTE (Micro-SIM)
  • Cardreader: SD/SDHC/SDXC/MMC
  • Webcam: 0.9 Megapixel
  • Extras: MIL-STD-810G, Pointing Stick, Fingerprint-Reader, Docking port
  • Things that work > Basically everything I care about:
    • Accelerated video
    • Keyboard
    • Touchpad/ClickPad (like expected in a modern laptop)
    • SSD
    • WiFi
    • Sound
    • HDMI out
    • Suspend to RAM
    • Webcam
  • Things that don't work
    • Fingerprint reader
    • Potentially anything I didn't test
    • Battery life is okay, but could be better.
  • Installation of the base system > I used a snapshot release of 12-CURRENT as the basis of my installation, particularly the one of 13th of December 2017. > I dd'ed it onto a memory stick and boot the laptop. I started a standard installation and created an encrypted ZFS pool on nvme0, using encryption, swap encryption and partition scheme "GPT (UEFI)". > After installation, it boots straight up.
  • Ports tree used > All work is based on a head ports tree from about Dec 18, 22:15 CET, which should be more or less r456672.
  • Preferred ClickPad configuration > As I'm not a fan of the the pointing stick, I disabled it in the bios. My final ClickPad configuration will be: Click to click (not tap), no middle button, right button in the lower right corner. As the old synaptics driver doesn't provide good thumb detection, libinput will be used.
  • Check out the laptop list on the FreeBSD wiki for compatibility: (https://wiki.freebsd.org/Laptops/)

FreeBSD desktop LiveCD creator

  • Introduction > The purpose of this tool is quickly generate bloat free images containing stock FreeBSD, and supported desktop environments.
  • Features
  • FreeBSD 11.1-RELEASE
  • AMD64
  • Gnome & KDE desktop environments
  • Hybrid DVD/USB image
  • Screenshots
  • [Gnome LiveCD])https://github.com/pkgdemon/comet/raw/master/screenshots/gnome-livecd.png?raw=true)
  • KDE LiveCD
  • System Requirements
  • FreeBSD 11.1, or higher for AMD64
  • 20GB of free disk space
  • 1GB of free memory
  • UFS, or ZFS
  • Initial Setup
  • Install the required packages: pkg install git grub2-pcbsd grub2-efi xorriso
  • Clone the repo: git clone https://www.github.com/pkgdemon/comet
  • Enter the directory for running the LiveCD creator: cd comet/src
  • Credentials for live media > User: liveuser > Password: freebsd

iXsystems

pledge() work in progress

I wanted to give an update that a two pledge-related changes are being worked on. The semantics and integration are complicated so it is taking some time. One is execpromises. This will become the 2nd argument of pledge(). This allows one to set the pledge for the new image after pledge "exec"-allowed execve(). A warning though: utilizing this in software isn't as easy as you might think! The fork+exec + startup sequences needed to be studied quite carefully to ensure the newly-executed child doesn't ask for more than the parent's execpromises. In my experiments such a circumstance is exceedingly common, so the problem is eased by introducing a new pledge feature which allows pledge violations to return ENOSYS or such rather than killing the process. This feature also needs to be used with great caution (especially in privileged programs) because programs which fail to observe errors may continue operating forward very incorrectly; you've lost the ability to catch it failing, and provide care by fixing the problem. The other is pledgepaths. The semantics are still being tuned a bit. Before the first call to pledge() in a process, one can pledgepath() directories. Then later after pledge(), file access operations only work if the traversal of the path crosses one of those pre-declared directories (but better make sure you don't move a directory, because the kernel remembers and reasons about the vnode of the directory rather than the path). Something similar is being worked on for files, but we are still adjusting that, as well as a flag parameter for the pledgepath() call which may constrain the operations done on such files. As such, pledgepath() will become a filesystem containment mechanism unlike chroot() because paths will still be based upon true /. Patience.


The anatomy of tee program on OpenBSD

The tee command is used to read content from standard input and displays it not only in standard output but also saves to other files simultaneously. The source code of tee in OpenBSD is very simple, and I want to give it an analysis: (1) tee leverages Singlely-linked List defined in sys/queue.h to manage outputted files (including standard output): struct list { SLIST_ENTRY(list) next; int fd; char *name; }; SLIST_HEAD(, list) head; ...... static void add(int fd, char *name) { struct list *p; ...... SLIST_INSERT_HEAD(&head, p, next); } int main(int argc, char *argv[]) { struct list *p; ...... SLIST_INIT(&head); ...... SLIST_FOREACH(p, &head, next) { ...... } } To understand it easily, I extract the macros from sys/queue.h and created a file which utilizes the marcos: &#35;define SLIST_HEAD(name, type) \ struct name { \ struct type *slh_first; \ } &#35;define SLIST_ENTRY(type) \ struct { \ struct type *sle_next; \ } &#35;define SLIST_FIRST(head) ((head)->slh_first) &#35;define SLIST_END(head) NULL &#35;define SLIST_EMPTY(head) (SLIST_FIRST(head) == SLIST_END(head)) &#35;define SLIST_NEXT(elm, field) ((elm)->field.sle_next) &#35;define SLIST_FOREACH(var, head, field) \ for((var) = SLIST_FIRST(head); \ (var) != SLIST_END(head); \ (var) = SLIST_NEXT(var, field)) &#35;define SLIST_INIT(head) { \ SLIST_FIRST(head) = SLIST_END(head); \ } &#35;define SLIST_INSERT_HEAD(head, elm, field) do { \ (elm)->field.sle_next = (head)->slh_first; \ (head)->slh_first = (elm); \ } while (0) struct list { SLIST_ENTRY(list) next; int fd; char *name; }; SLIST_HEAD(, list) head; int main(int argc, char *argv[]) { struct list *p; SLIST_INIT(&head); SLIST_INSERT_HEAD(&head, p, next); SLIST_FOREACH(p, &head, next) { } } Then employed gcc‘s pre-processing function: &#35; gcc -E slist.c &#35; 1 "slist.c" &#35; 1 "<built-in>" &#35; 1 "<command-line>" &#35; 1 "slist.c" &#35; 30 "slist.c" struct list { struct { struct list *sle_next; } next; int fd; char *name; }; struct { struct list *slh_first; } head; int main(int argc, char *argv[]) { struct list *p; { ((&head)->slh_first) = NULL; }; do { (p)->next.sle_next = (&head)->slh_first; (&head)->slh_first = (p); } while (0); for((p) = ((&head)->slh_first); (p) != NULL; (p) = ((p)->next.sle_next)) { } } It becomes clear now! The head node in list contains only 1 member: slhfirst, which points to the first valid node. For the elements in the list, it is embedded with next struct which uses slenext to refer to next buddy. (2) By default, tee will overwrite the output files. If you want to append it, use -a option, and the code is as following: while (*argv) { if ((fd = open(*argv, O_WRONLY | O_CREAT | (append ? O_APPEND : O_TRUNC), DEFFILEMODE)) == -1) { ...... } ...... } (3) The next part is the skeleton of saving content to files: while ((rval = read(STDIN_FILENO, buf, sizeof(buf))) > 0) { SLIST_FOREACH(p, &head, next) { n = rval; bp = buf; do { if ((wval = write(p->fd, bp, n)) == -1) { ...... } bp += wval; } while (n -= wval); } } We need to iterates every opened file descriptor and write contents into it. (4) Normally, theinterrupt signal will cause tee exit: &#35; tee fdkfkdfjk fdkfkdfjk ^C &#35; To disable this feature, use -i option: &#35; tee -i fdhfhd fdhfhd ^C^C The corresponding code is like this: ...... case 'i': (void)signal(SIGINT, SIG_IGN); break;


Beastie Bits

Feedback/Questions


  • Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

NOTE: please mention that we need more questions in. We’re getting very low again.

Latest News

New announcement

2017-05-25

We understand that Michael Dexter, Brad Davis, and George Rosamond think there should be more real news....

Two Year Anniversary

2015-08-08

We're quickly approaching our two-year anniversary, which will be on episode 105. To celebrate, we've created a unique t-shirt design, available for purchase until the end of August. Shirts will be shipped out around September 1st. Most of the proceeds will support the show, and specifically allow us to buy...

New discussion segment

2015-01-17

We're thinking about adding a new segment to the show where we discuss a topic that the listeners suggest. It's meant to be informative like a tutorial, but more of a "free discussion" format. If you have any subjects you want us to explore, or even just a good name...

How did you get into BSD?

2014-11-26

We've got a fun idea for the holidays this year: just like we ask during the interviews, we want to hear how all the viewers and listeners first got into BSD. Email us your story, either written or a video version, and we'll read and play some of them for...


Episode 243: Understanding The Scheduler

2018-04-25

This episode was brought to you by Headlines OpenBSD 6.3 released Punctual as ever, OpenBSD 6.3 has been releases with the following features/changes: > Improved HW support, including: > SMP support on OpenBSD/arm64 platforms > vmm/vmd improvements: > IEEE 802.11 wireless stack improvements > Generic network stack improvements > Installer improvements > Routing daemons and other userland network improvements > Security...

Episode 242: Linux Takes The Fastpath

2018-04-18

Direct Download:MP3 AudioVideo This episode was brought to you by Headlines TrueOS STABLE 18.03 Release The TrueOS team is pleased to announce the availability of a new STABLE release of the TrueOS project (version 18.03). This is a special release due to the security issues impacting the computing world since the beginning...

Episode 241: Bowling in the LimeLight

2018-04-11

Direct Download:MP3 AudioVideo This episode was brought to you by Headlines [Other big ZFS improvements you might have missed] 9075 Improve ZFS pool import/load process and corrupted pool recovery > One of the first tasks during the pool load process is to parse a config provided from userland that describes what devices the pool is...

Episode 240: TCP Blackbox Recording

2018-04-04

Direct Download:VideoMP3 Audio This episode was brought to you by Headlines [A number of Upstream ZFS features landed in FreeBSD this week] 9188 increase size of dbuf cache to reduce indirect block decompression With compressed ARC (6950) we use up to 25% of our CPU to decompress indirect blocks, under a workload of...