Episode 227
The long core dump
January 3rd, 2018
1 hr 31 mins 54 secs
Your Hosts
Tags
About this Episode
We walk through dumping a PS4 kernel in only 6 days, tell you the news that NetBSD 7.1.1 has been released, details on how to run FreeBSD on a Thinkpad T470, and there’s progress in OpenBSD’s pledge.
This episode was brought to you by
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](www.NetBSD.org)
+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 kern_reboot with the RB_DUMP 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 mdbg_run_dump, which can be called from panic or directly from trap_fatal. 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 mdbg_run_dump 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 mdbg_run_dump - 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, sysdump__internal_call_readuser 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, sysdump__internal_call_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
- StorageCrypter Ransomware: Security Threat or Clickbait?
###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:#define SLIST_HEAD(name, type) \ struct name { \ struct type *slh_first; /* first element */ \ } #define SLIST_ENTRY(type) \ struct { \ struct type *sle_next; /* next element */ \ } #define SLIST_FIRST(head) ((head)->slh_first) #define SLIST_END(head) NULL #define SLIST_EMPTY(head) (SLIST_FIRST(head) == SLIST_END(head)) #define SLIST_NEXT(elm, field) ((elm)->field.sle_next) #define SLIST_FOREACH(var, head, field) \ for((var) = SLIST_FIRST(head); \ (var) != SLIST_END(head); \ (var) = SLIST_NEXT(var, field)) #define SLIST_INIT(head) { \ SLIST_FIRST(head) = SLIST_END(head); \ } #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:# gcc -E slist.c # 1 "slist.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "slist.c" # 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: slh_first, which points to the first valid node. For the elements in the list, it is embedded with next struct which uses sle_next 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:# tee fdkfkdfjk fdkfkdfjk ^C #> To disable this feature, use -i option:# tee -i fdhfhd fdhfhd ^C^C> The corresponding code is like this:...... case 'i': (void)signal(SIGINT, SIG_IGN); break;*** ##Beastie Bits + What I learned from reading the OpenBSD's network stack source code + Broadcom BCM43224 and BCM43225 Wi-Fi cards now supported by bwn(4) + Ingo details searching man pages + DTrace & ZFS Being Updated On NetBSD, Moving Away From Old OpenSolaris Code + Linux Professional Institute and BSD Certification Group Join Efforts + The FreeBSD Foundation thanks Donors ##Feedback/Questions + Alex - My first freebsd bug + John - Suggested Speakers + Todd - Two questions + Matthew - CentOS to FreeBSD ***
