Feed aggregator

Building Cognitive Applications with IBM Watson Services: Volume 6 Speech to Text and Text to Speech

IBM Redbooks Site - Fri, 05/26/2017 - 09:30
Redbook, published: Fri, 26 May 2017

The Building Cognitive Applications with IBM Watson Services series is a seven-volume collection that introduces IBM® Watson™ cognitive computing services.

Categories: Technology

In the news

iPhone J.D. - Fri, 05/26/2017 - 01:15

Walt Mossberg has been writing about personal technology since 1991, mostly for the Wall Street Journal, but more recently for Recode.  In his final column before he retires, Mossberg considers the future of personal technology.  For many years, it was all about computers.  Lately, the focus in personal technology has been the iPhone.  Mossberg thinks that ambient computing may be the next big thing, the idea that the environment around us is intelligent and responsive, sort of like Siri or the Amazon Echo, with more features, always aware of what you are doing or saying.  It is a fascinating piece that makes me think about what may be coming in the near future.  And now, the news of note from the past week:

  • Florida attorney Katie Floyd and California attorney David Sparks released a great episode of their Mac Power Users podcast devoted to hidden iOS features.  They are joined by Clayton Morris, and the episode is full of great tips.  Worth a listen.
  • South Carolina attorney Justin Kahn notes that NotesPlus, a note taking app, was updated to version 5.0.  Notably, the update adds iPhone support.
  • Nick Statt of The Verge discusses the interesting background of Anker, a company that makes great accessories for the iPhone and iPad.  I'm a big fan of the Anker PowerPort 6 I reviewed in 2015, and I still use it every time I travel.  Anker makes lots of other great products too.  For example, I see that you can get an Anker PowerCore external battery with 10,000 mAh — enough to charge an iPhone more than three times over — for only $27 on Amazon right now.
  • Richard Thompson of The Advocate describes how Ochsner Hospital in New Orleans is using the Apple Watch to help patients with high blood pressure.
  • Mike Schmitz of The Sweet Setup explains how to remove the GPS info from an iPhone picture so that you can share a picture with someone else without also sharing the location data for the picture.
  • If you read my CarPlay review, then you know that I'm a big fan of the technology.  In the past, many Ford cars did not support CarPlay because Ford promoted its own Sync software.  Surprisingly, Ford announced this week that it is updating 2016 model Ford vehicles to support CarPlay, as reported by Ben Lovejoy of 9to5Mac.  It is rare for any car manufacturer to add new features to old cars, especially something like CarPlay.  This is great news for owners of those vehicles who have an iPhone.
  • David Pogue of Yahoo discusses the features in the new Samsung Galaxy 8 that are not on the iPhone 7, and indicates which ones are actually useful and might be nice to have on the iPhone.
  • Brent Dirks of AppAdvice discusses an update to the Duet Display app which lets you use an Apple Pencil to draw on your Mac or PC screen.
  • Buster Hein of Cult of Mac reports that a new FCC filing by Apple reveals that Apple has started testing 5G network technology with the iPhone, technology that could provide speeds up to 1Gpbs.  Wow.  And it seems like just yesterday I was excited to upgrade my Mac's modem from 28K to 56K.
  • Serenity Caldwell of iMore discusses a recent Stanford study on smartwatch health calculations.  The Apple Watch is best at monitoring heart rate, but all devices are less accurate at measuring calories burned.
  • For Global Accessibility Awareness Day on May 18, Apple released seven videos showing how people with disabilities take advantage of Apple products.  Jim Dalrymple of The Loop shows off all seven videos on this page.
  • And finally, Apple unveiled a new part of its website devoted to convincing Android users to switch to iPhone.  The primary message is let folks know that the switch won't be complicated; Apple even has an Android app which moves everything over.  But the webpage, and associated short videos, also explain why life is better on iPhone.  Here is one example, which points out that Apple does more to protect privacy on the iPhone than Google does on Android:


Categories: iPhone Web Sites

Building Cognitive Applications with IBM Watson Services: Volume 4 Natural Language Classifier

IBM Redbooks Site - Thu, 05/25/2017 - 09:30
Redbook, published: Thu, 25 May 2017

The Building Cognitive Applications with IBM Watson Services series is a seven-volume collection that introduces IBM® Watson™ cognitive computing services.

Categories: Technology

Building Cognitive Applications with IBM Watson Services: Volume 5 Language Translator

IBM Redbooks Site - Thu, 05/25/2017 - 09:30
Redbook, published: Thu, 25 May 2017

The Building Cognitive Applications with IBM Watson Services series is a seven-volume collection that introduces IBM® Watson™ cognitive computing services.

Categories: Technology

Building Cognitive Applications with IBM Watson Services: Volume 2 Conversation

IBM Redbooks Site - Wed, 05/24/2017 - 09:30
Redbook, published: Wed, 24 May 2017

The Building Cognitive Applications with IBM Watson Services series is a seven-volume collection that introduces IBM® Watson cognitive computing services.

Categories: Technology

Review: Renogy E.LUMEN Solar Flashlight iPhone Charger

iPhone J.D. - Wed, 05/24/2017 - 00:35

Five years ago, Apple CEO Tim Cook was asked about Microsoft's decision to merge laptop and tablet computers into one device.  Cook said that he thought it was better to keep the iPad and the MacBook different devices, explaining:  "Anything can be forced to converge.  But the problem is that the products are about tradeoffs.  You begin to make tradeoffs to the point that what you have left at the end of the day doesn't please anyone.  You can converge a toaster and a refrigerator, but you know those things are probably not going to be pleasing to the user."  Sometimes convergence is great, like peanut butter and jelly.  Sometimes not so much, like Cook's theoretical toaster fridge.  One cannot help thinking about convergence when viewing the E.LUMEN, a multi-function flashlight made by Renogy.

Renogy was founded a few years ago by Yi Li while she was getting a Ph.D. in physics at Louisiana State University.  The company was created to sell solar products, first as a part of LSU's Technology Center, then it was based in Southern California, and now the company operates out of Ontario, Canada.  Renogy makes many different types of solar products, but one of its smallest products is the E.LUMEN.  The company sent me a free review unit, and I have been using it for the past week (as have my kids).

Solar power

The primary function of the E.LUMEN is to serve as a solar-powered flashlight.  Expose the solar panel on the side of the E.LUMEN to sunlight during the day, and you can use the flashlight at night, without having to worry about batteries.  The E.LUMEN rests on a side (it isn't completely round like most other flashlights) so the solar panel will stay pointing up towards the sun.

Renogy says that if the E.LUMEN is at 0%, it takes about 29 hours of sunlight to get back to 100%.  Renogy also says that the main flashlight mode of the flashlight can last 3-4 hours, but it lasted much longer than that in my tests.  I turned on the flashlight at 9pm one night, and it was still going at 7am in the morning, although it was much dimmer.  It took a few more hours for the E.LUMEN to be completely dead.  I then left it outside for two days, and it charged up again.  Unfortunately, there is no indication on the E.LUMEN of how much charge the device has, so I don't know how close I got to a full charge after two days outside.

Three Lighting Modes

The main flashlight has three modes, and each of those modes has multiple settings.

The headlight mode functions like a normal flashlight.  There are four settings within that mode, and you switch between them by pressing the main button on the flashlight.  The bright setting uses 3W of LED light to emits 200 lumens of light for 200 meters.  Press the button again to switch to a dimmer setting, press the button a third time to switch to a strobe mode (perfect for attracting attention, blinding an intruder, or hosting a disco party), and press the button a fourth time to turn off the headlight.

I'm not in the business of reviewing flashlights, but the E.LUMEN headlight mode seems very bright to me, and based on some research I did on the Internet, this output seems similar to other flashlights in its class.  The light beam is brighter in the center (and unlike some other nice flashlights, you cannot twist to adjust the size of the bright center of the beam).  It is bright enough that you will hurt your eyes if you look directly at it.  Unless you are leading a search party or exploring a cave, I suspect that you will find this to be a sufficiently bright flashlight.  It's certainly brighter than the others that I have in my house.

If you hold down the button for three seconds, you switch to the second mode, the white floodlight mode.  This mode illuminates 10 small lights on the side of the flashlight (around the solar panels) at 2W, 150 lumens.  This mode is nice because it gives you a wide range of light, which could be useful if you want to shine light over a wide area to get some work done, or if you want to light up the inside of a tent.  Press the button a second time to switch to a dim setting, and a third time to switch it off.

The final mode is the red strobe light mode, which I'm sure is useful for attracting attention in an emergency.  Presh the button a second time for a dim red strobe light, and a third time to turn if off.

iPhone charger

A solar-powered flashlight contains a rechargeable battery, and people use rechargeable batteries to charge an iPhone, so why not combine those two functions?  If you twist off the bottom of the E.LUMEN, two ports are revealed.  One is a standard USB port.  Plug in your USB-to-Lightning cable and you can charge your iPhone.

The battery is a 2,000 mAh Lithium ion battery with a 1 Amp output.  That should be enough power to almost fully charge an iPhone 7 once, or enough to charge an iPhone 7 Plus around 50%.

Charging an iPhone from a flashlight might seem a little goofy at first, but if you are camping or if there is an extended power outage, being able to use solar power to charge the battery and then charge an iPhone could be incredibly useful.

Next to the USB port is a Micro USB port, which is used only for input.  If you need to charge the E.LUMEN and either don't have access to solar power or want to charge it more quickly, just use any standard Micro USB cable (one is included with the E.LUMEN).  Unlike the 29 hours of solar power required to fully recharge an E.LUMEN, you can recharge via Micro USB in only 6 hours.

But wait, there's more!

Just in case a solar-powered battery/flashlight/strobe light/iPhone charger isn't enough convergence for you, the E.LUMEN has many more tricks up its sleeve.  One side of the top of the flashlight has a seatbelt cutter.  The other side has a high-strength, alloy glass-shattering hammer.  With those two tools, the E.LUMEN seems like a useful device to keep in your car's glove compartment. 

Also, the side of the E.LUMEN has a small magnet.  If you have something metallic and flat, like the side of a filing cabinet, the magnet is strong enough to hold up the flashlight.  So the magnet makes it easier to store the E.LUMEN.

Finally, the very bottom of the E.LUMEN has a compass.  It is on the part that you remove to expose the USB ports, so you could hold and use the compass without having to hold the entire flashlight.  I haven't had a need for a compass since I was a Boy Scout, and of course the iPhone itself has a compass app, but if you have a need for a small compass, the E.LUMEN has you covered.

Putting it all together

If you get trapped in your car in the middle of nowhere, you can use the E.LUMEN to cut your seatbelt off and shatter the glass window to escape from the car.  Then you can use the compass to get your bearings, use the red strobe light to draw attention to yourself and seek help, and if nightfall comes you have two types of flashlights to look around.  And if you haven't drained the battery by using the flashlight, you can recharge your iPhone to call for help.  Although perhaps using the phone to call someone for help should have been the first thing that you did.

Sure, that scenario is farfetched, but I have to admit that it does seem nice to have a flashlight with so many other functions — even if you never to use all of those functions at one time.  Best of all, the E.LUMEN feels like a nice flashlight in your hand.  It weighs 0.68 lbs, which is not too heavy but sturdy.  It is made of strong aluminum (remember, this thing is strong enough to work as a glass-shattering hammer) and looks like it can stand up to a lot of abuse.  The feel is somewhat similar to the feel of a Maglite flashlight if you have used one of those.  It has an IP54 rating, which means that it has reasonably good protection against dust, and it is OK for water to splash on it (e.g. rain), but you shouldn't direct a jet of water at it and you shouldn't let it go underwater. 

If you are looking to get a flashlight for camping or for your car, or even a flashlight that could be used during emergency situations in your house, the E.LUMEN seems like a great option to me.  You get all of the features that you expect from a traditional flashlight, plus lots of extra features such as an iPhone charger that could turn out to be quite useful in certain situations.  Using solar power on a flashlight can be good or bad depending upon the circumstances; you cannot quickly swap out batteries like you can with a standard flashlight, but you also don't need to worry about keeping (and carrying around) those extra batteries because you can use the sun to recharge.  In short, I was worried that the E.LUMEN would be a toaster fridge, but after using it and thinking about it for a week, I like the product and it seems more like a yummy PB&J.

Click here to get the Renogy E.LUMEN Solar Flashlight from Amazon ($24.99).

Categories: iPhone Web Sites

SAP HANA and ESS: A Winning Combination

IBM Redbooks Site - Tue, 05/23/2017 - 09:30
Redpaper, published: Tue, 23 May 2017

SAP HANA on IBM® POWER® is an established HANA solution with which customers can run HANA-based analytic and business applications on a flexible IBM Power-based infrastructure.

Categories: Technology

IBM PowerHA SystemMirror V7.2.1 for IBM AIX Updates

IBM Redbooks Site - Tue, 05/23/2017 - 09:30
Redbook, published: Tue, 23 May 2017

This IBM® Redbooks® publication helps strengthen the position of the IBM PowerHA® SystemMirror® solution with a well-defined and documented deployment models within an IBM Power Systems™ virtualized environment, which provides customers with a planned foundation for business resilience and disaster recovery for their IBM Power Systems infrastructure solutions.

Categories: Technology

Building Cognitive Applications with IBM Watson Services: Volume 3 Visual Recognition

IBM Redbooks Site - Mon, 05/22/2017 - 09:30
Redbook, published: Mon, 22 May 2017

The Building Cognitive Applications with IBM Watson Services series is a seven-volume collection that introduces IBM® Watson cognitive computing services.

Categories: Technology

Oracle on IBM z Systems

IBM Redbooks Site - Mon, 05/22/2017 - 09:30
Redbook, published: Mon, 22 May 2017

Oracle Database 12c Release 1 running on Linux is available for deployment on IBM® z Systems®.

Categories: Technology

Implementing IBM Spectrum Virtualize software only

IBM Redbooks Site - Fri, 05/19/2017 - 09:30
Redpaper, published: Fri, 19 May 2017

This IBM® Redpaper™ publication provides a broad understanding of IBM Spectrum Virtualize™ software only and how it fits into to the IBM SAN Volume Control and IBM Storwize® families.

Categories: Technology

In the news

iPhone J.D. - Fri, 05/19/2017 - 01:38

New York attorney Nicole Black discusses a new ABA Opinion (Formal Opinion 477) on legal ethics issues surrounding email and other methods of communicating with clients.  The bottom line is that you need to determine what is the right method of communication depending upon the sensitivity of the information, the risks of disclosure, etc., all of which requires a case-by-case analysis.  The lack of a black letter rule makes it harder for attorneys.  For example, you can't just say that unencrypted email is always appropriate, becomes sometimes it isn't.  So essentially, before you send any email or text, before you use Dropbox to share a file, and before you decide whether to meet in person or just use your iPhone, you need to pause and analyze what approach is reasonable for a specific communication with your client regarding a specific topic.  And now, the news of note from the past week:

  • California attorney David Sparks recommends adding a strap to your AirPods when using a bicycle.
  • South Carolina attorney Justin Kahn discusses a recent update to Microsoft's OneNote app.
  • Things is a powerful app for tracking your to do items (my wife uses the app every day), and this week it was updated to version 3.  Lory Gil of iMore discusses what is new in Things 3.
  • Mike Wuerthele of AppleInsider discusses the AT&T Call Protect app.  I reviewed that app earlier this year, and I still like it.
  • Steven Levy was given a tour of the new Apple Park campus and write a great article about it for Wired.
  • In an article for Macworld, Jason Snell discusses Apple's new Apple Park campus, noting that it is the last great Apple product by Steve Jobs.
  • In an article for Macworld, Dan Moren says that health is Apple's next killer app.
  • Christina Farr of CNBC reports that Apple CEO Tim Cook has been seen wearing a device that tracks blood sugar connected to his Apple Watch, a suggestion that Apple may be developing a glucose tracker for folks with diabetes.
  • Sarah Perez of TechCrunch notes that Apple is now doing even more educational classes at its stores and has launched a new website for the classes.
  • This one is really neat.  Charlie Sorrel of Cult of Mac walks through the steps to use the Photos app on an iPhone or iPad (this works better with a big iPad screen) to see a 3D view of a city with flags indicating photos that you took in different areas of the city.  I had no idea you could do that.  Very cool.
  • Jonny Evans of ComputerWorld shares 15 Apple Watch tricks.  One on the list that I didn't know about was the ability to turn the digital crown to gently illuminate the watch face, useful if you want to be discreet and/or are in a dark room.
  • Rene Ritchie of iMore tells the story of a man who was saved by Siri.  He was burned in an explosion and couldn't use his fingers to dial 911, but he was able to ask Siri to call 911 for him.
  • Last week, I noted that Apple released three videos with tips on using an iPhone to take photographs.  There are actually many more videos, and they are all collected on this page on the Apple website entitled "How to shoot on iPhone 7."
  • And finally, this week Apple released a new ad to show off the portrait mode feature of the iPhone 7 Plus.  The commercial was filmed at a barbershop right here in New Orleans.  It's a cute commercial.  One minor thing I noted — at the start of the commercial, you see a lawyer's office on the left side of the screen next to the barbershop.  I know where this commercial was shot (the Family Barber Shop at 8112 Oak Street), and while I haven't yet driven over there to confirm, I think that Apple digitally added the law firm sign over what is actually a yoga studio.  Indeed, according to the Louisiana State Bar Association website, there is no "Donald M. Taylor" practicing in Louisiana.  Interesting that Apple thought that the ad would look better if the barbershop was next to a law firm.  I guess it just shows you that everyone loves lawyers and wants to be near lawyers.  Here is the ad, which Apple calls Barbers:

Categories: iPhone Web Sites

Install iOS updates, even if they seem minor

iPhone J.D. - Wed, 05/17/2017 - 22:50

Earlier this week, Apple released iOS 10.3.2 for iPhone and iPad.  Any X.X.1, X.X.2, etc. update is typically considered a minor update which adds no new features and just addresses some bugs and/or security issues.  Sure enough, the release notes for iOS 10.3.2 say that it "includes bug fixes and improves the security of your iPhone or iPad."  You can get more details on the security improvements on the Apple website; where you will learn that iOS 10.3.2 fixes things like memory leaks that could allow an app to get kernel privileges, a flaw that could let an app execute arbitrary code, and a memory issue that could allow an app to cause a denial of service.  But the concept of "security updates" may seem so unexciting that I'm sure that many folks conclude that they don't want to waste the time installing the update.

This week we learned, once again, that security patches are important.  As noted in numerous news stories such as this one from the Washington Post, a few years ago the NSA developed something it called EternalBlue, a hacking tool that the NSA could use to access computers to help U.S. interests.  But the tool was stolen by hackers, and after the NSA discovered that, the NSA revealed the tool to Microsoft so that Microsoft could patch the flaw in Windows that the tool exploited.  Microsoft released that patch in March of 2017, but many computers had not yet been updated, and as a result ... well, I presume you heard about all of the computers around the world that were the victim of ransomware a few days ago, including a number of hospitals in London.  As the Post article notes:  "The malicious code at the heart of the WannaCry virus that hit computer systems globally late last week was apparently stolen from the NSA, repackaged by cybercriminals and unleashed on the world for a cyberattack that now ranks as among the most disruptive in history."

From a worldwide perspective, WannaCry may be one of the most disruptive cyberattacks.  But for Rhode Island law firm Moses Afonso Ryan, the most disruptive cyberattack was last year when a hacker took control of its computers and the firm had to pay a $25,000 ransom to get access to its systems again after three months.  Even worse, as reported this month by Debra Cassens Weiss in ABA Journal, the law firm lost $700,000 in billings due to the attack, and its business interruption insurer is denying coverage.

It is unfortunate, although perhaps unsurprising, for a law firm to be a victim of hackers.  I'm more amazed that the NSA — which must be one of the most security-conscious organizations in the world — could even be the victim of hackers.  If the NSA is vulnerable, anyone is vulnerable.  And as a side note, this is the sort of thing I was thinking of when I noted in the past during the FBI vs. Apple litigation that it was foolhardy for the FBI to ask Apple to create a backdoor for the government to access iPhones.  Even if a special key was created only for the government, and even if the government honestly tried to keep that key secret, the risk of it being accessed by bad guys is simply too great to ignore.

However, my goal today is not to reignite the FBI vs. Apple debate, but instead to point out that virtually all software and hardware can have bugs and flaws.  Fortunately, when these problems are discovered, they can typically be patched.  I don't think I've ever seen an iOS update that doesn't include at least some security patches.  Hopefully, iOS 10.3.2 wasn't patching anything as dangerous as the Windows flaw used by EternalBlue and the WannaCry virus, but you never know.  What I do know is that when Apple (or Microsoft or any trusted vendor) releases a security update, you should install the update.  Maybe you don't want to install it immediately, just in case the update itself has a flaw.  That happened in 2013 with iOS 6.1, in 2014 with iOS 8.0.1, in 2016 with iOS 10.0, and other times as well.  But Apple typically discovers those bugs very quickly, and then pulls the update until the issue is fixed.  Once an update has been out for a day or two, you can feel safe installing the update.  Of course it is always best to backup your iPhone or iPad before installing any update.  (I usually practice what I preach, but to be honest sometimes I just install the update and cross my fingers.)

If you haven't yet updated to iOS 10.3.2, it is time to do so now.  Open the Settings app, tap General, and tap Software Update.

Categories: iPhone Web Sites

Building Cognitive Applications with IBM Watson Services: Volume 7 Natural Language Understanding

IBM Redbooks Site - Wed, 05/17/2017 - 09:30
Draft Redbook, last updated: Wed, 17 May 2017

The Building Cognitive Applications with IBM® Watson Services series is a seven-volume collection that introduces IBM Watson® cognitive computing services.

Categories: Technology

Web Maintainability Industry Survey: How Do We Maintain?

A list Apart development site - Tue, 05/16/2017 - 12:05

A note from the editors: As a community, we can learn so much from discovering what other developers are doing around the world. We encourage everyone to participate in this very brief survey created by Jens Oliver Meiert. Jens will share the results—and an updated guide to web maintainability based on the findings—in a few weeks.

How often do we consider the maintenance and general maintainability of our websites and apps? What steps do we actively take to make and keep them maintainable? What stands in the way when we maintain our and other people’s projects?

Many of us, as web developers, know very well how to code something. But whether we know just as well how to maintain what we—and others—have written, that is not so clear. Our bosses and clients may not always think about maintenance down the road, either.

As an O’Reilly author and former Googler, I’ve been studying the topic of maintainability since 2008—and we have yet to gather our industry’s views on the subject. To help us all get a better picture of how we maintain and how we can maintain more effectively, I set up a brief, unassuming survey (announcement) and kindly ask for your assistance.

The survey aims to collect specific practices and resources—in other words, your views on current practices (both useful and harmful) and everything you find helpful:

  • What helps maintenance?
  • What prevents maintenance?
  • What resources do developers turn to for improving maintainability?

The outcome of the survey and an updated guide to web maintainability will be published in a few weeks on my website, meiert.com (and noted on my Twitter profile). Thank you for your support.

Categories: Technology

POWER8 High-performance Computing Guide IBM Power System S822LC (8335-GTB) Edition

IBM Redbooks Site - Sun, 05/14/2017 - 09:30
Redbook, published: Sun, 14 May 2017

This IBM® Redbooks® publication documents and addresses topics to provide step-by-step customizable application and programming solutions to tune application and workloads to use IBM Power Systems™ hardware architecture.

Categories: Technology

IBM Spectrum Computing Solutions

IBM Redbooks Site - Fri, 05/12/2017 - 09:30
Redbook, published: Fri, 12 May 2017

This IBM® Spectrum Computing Solutions Redbooks® publication is a follow-up book to update each of the available offerings that are part of the IBM portfolio of Cloud, analytics, technical computing, and high-performance computing (HPC) solutions for our clients.

Categories: Technology

In the news

iPhone J.D. - Thu, 05/11/2017 - 19:39

One of the most useful apps in my law practice is GoodReader, the primary app that I use to read and annotate PDF files.  The last major update was GoodReader 4, released in 2014.  Since then, the developer of the app, Yuri Selukoff (whose mother was a patent attorney), obtained a difficult-to-receive EB-1 Visa (reserved for foreign nationals with extraordinary abilities) and moved from Moscow to San Francisco, as described in this interesting profile of Selukoff from last year on the Inside BlackBerry blog.  I was pleased to see a recent confirmation on the GoodReader Facebook page that Selukoff is hard at work on GoodReader 5.  There is no release date yet, but hopefully the reason for Selukoff's recent post is that the release date is coming soon.  Selukoff says in that post:  "It’s a huge update with a completely new design and new features, some you may not even know you'll want until you've seen them!  So fear not, and get ready (or for those of you who’ve been ready, stay ready) – GoodReader 5.0 is on the way!"  For all of us who use GoodReader in our law practices – and I know from the feedback I receive from iPhone J.D. readers that there are many of us – it will be great to see a major update to this essential app.  And now, the news of note from the past week:

Categories: iPhone Web Sites

Oracle on z Systems

IBM Redbooks Site - Thu, 05/11/2017 - 09:30
Draft Redbook, last updated: Thu, 11 May 2017

Oracle Database 12c Release 1 running on Linux is available for deployment on IBM® z Systems®.

Categories: Technology

Exploiting the Linux kernel via packet sockets

Google Project Zero - Wed, 05/10/2017 - 12:33
Guest blog post, posted by Andrey KonovalovIntroductionLately I’ve been spending some time fuzzing network-related Linux kernel interfaces with syzkaller. Besides the recently discovered vulnerability in DCCP sockets, I also found another one, this time in packet sockets. This post describes how the bug was discovered and how we can exploit it to escalate privileges.
The bug itself (CVE-2017-7308) is a signedness issue, which leads to an exploitable heap-out-of-bounds write. It can be triggered by providing specific parameters to the PACKET_RX_RING option on an AF_PACKET socket with a TPACKET_V3 ring buffer version enabled. As a result the following sanity check in the packet_set_ring() function in net/packet/af_packet.c can be bypassed, which later leads to an out-of-bounds access.
4207                 if (po->tp_version >= TPACKET_V3 &&4208                     (int)(req->tp_block_size -4209                           BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv)) <= 0)4210                         goto out;
The bug was introduced on Aug 19, 2011 in the commit f6fb8f10 ("af-packet: TPACKET_V3 flexible buffer implementation") together with the TPACKET_V3 implementation. There was an attempt to fix it on Aug 15, 2014 in commit dc808110 ("packet: handle too big packets for PACKET_V3") by adding additional checks, but this was not sufficient, as shown below. The bug was fixed in 2b6867c2 ("net/packet: fix overflow in check for priv area size") on Mar 29, 2017.
The bug affects a kernel if it has AF_PACKET sockets enabled (CONFIG_PACKET=y), which is the case for many Linux kernel distributions. Exploitation requires the CAP_NET_RAW privilege to be able to create such sockets. However it's possible to do that from a user namespace if they are enabled (CONFIG_USER_NS=y) and accessible to unprivileged users.
Since packet sockets are a quite widely used kernel feature, this vulnerability affects a number of popular Linux kernel distributions including Ubuntu and Android. It should be noted, that access to AF_PACKET sockets is expressly disallowed to any untrusted code within Android, although it is available to some privileged components. Updated Ubuntu kernels are already out, Android’s update is scheduled for July.Syzkaller
The bug was found with syzkaller, a coverage guided syscall fuzzer, and KASAN, a dynamic memory error detector. I’m going to provide some details on how syzkaller works and how to use it for fuzzing some kernel interface in case someone decides to try this.
Let’s start with a quick overview of how the syzkaller fuzzer works. Syzkaller is able to generate random programs (sequences of syscalls) based on manually written template descriptions for each syscall. The fuzzer executes these programs and collects code coverage for each of them. Using the coverage information, syzkaller keeps a corpus of programs, which trigger different code paths in the kernel. Whenever a new program triggers a new code path (i.e. gives new coverage), syzkaller adds it to the corpus. Besides generating completely new programs, syzkaller is able to mutate the existing ones from the corpus.
Syzkaller is meant to be used together with dynamic bug detectors like KASAN (detects memory bugs like out-of-bounds and use-after-frees, available upstream since 4.0), KMSAN (detects uses of uninitialized memory, prototype was just released) or KTSAN (detects data races, prototype is available). The idea is that syzkaller stresses the kernel and executes various interesting code paths and the detectors detect and report bugs.
The usual workflow for finding bugs with syzkaller is as follows:
  1. Setup syzkaller and make sure it works. README and wiki provides quite extensive information on how to do that.
  2. Write template descriptions for a particular kernel interface you want to test.
  3. Specify the syscalls that are used in this interface in the syzkaller config.
  4. Run syzkaller until it finds bugs. Usually this happens quite fast for the interfaces, that haven’t been tested with it previously.

Syzkaller uses it’s own declarative language to describe syscall templates. Checkout sys/sys.txt for an example or sys/README.md for the information on the syntax. Here’s an excerpt from the syzkaller descriptions for AF_PACKET sockets that I used to discover the bug:
resource sock_packet[sock]
define ETH_P_ALL_BE htons(ETH_P_ALL)
socket$packet(domain const[AF_PACKET], type flags[packet_socket_type], proto const[ETH_P_ALL_BE]) sock_packet
packet_socket_type = SOCK_RAW, SOCK_DGRAM
setsockopt$packet_rx_ring(fd sock_packet, level const[SOL_PACKET], optname const[PACKET_RX_RING], optval ptr[in, tpacket_req_u], optlen len[optval])setsockopt$packet_tx_ring(fd sock_packet, level const[SOL_PACKET], optname const[PACKET_TX_RING], optval ptr[in, tpacket_req_u], optlen len[optval])
tpacket_req { tp_block_size int32 tp_block_nr int32 tp_frame_size int32 tp_frame_nr int32}
tpacket_req3 { tp_block_size int32 tp_block_nr int32 tp_frame_size int32 tp_frame_nr int32 tp_retire_blk_tov int32 tp_sizeof_priv int32 tp_feature_req_word int32}
tpacket_req_u [ req tpacket_req req3 tpacket_req3] [varlen]
The syntax is mostly self-explanatory. First, we declare a new type sock_packet. This type is inherited from an existing type sock. That way syzkaller will use syscalls which have arguments of type sock on sock_packet sockets as well.
After that, we declare a new syscall socket$packet. The part before the $ sign tells syzkaller what syscall it should use, and the part after the $ sign is used to differentiate between different kinds of the same syscall. This is particularly useful when dealing with syscalls like ioctl. The socket$packet syscall returns a sock_packet socket.
Then setsockopt$packet_rx_ring and setsockopt$packet_tx_ring are declared. These syscalls set the PACKET_RX_RING and PACKET_TX_RING socket options on a sock_packet socket. I’ll talk about these options in details below. Both of them use the tpacket_req_u union as a socket option value. This union has two struct members tpacket_req and tpacket_req3.
Once the descriptions are added, syzkaller can be instructed to fuzz packet-related syscalls specifically. This is what I provided in the syzkaller manager config:
"enable_syscalls": [ "socket$packet", "socketpair$packet", "accept$packet", "accept4$packet", "bind$packet", "connect$packet", "sendto$packet", "recvfrom$packet", "getsockname$packet", "getpeername$packet", "listen", "setsockopt", "getsockopt", "syz_emit_ethernet" ],
After a few minutes of running syzkaller with these descriptions I started getting kernel crashes. Here’s one of the syzkaller programs that triggered the mentioned bug:
mmap(&(0x7f0000000000/0xc8f000)=nil, (0xc8f000), 0x3, 0x32, 0xffffffffffffffff, 0x0)
r0 = socket$packet(0x11, 0x3, 0x300)
setsockopt$packet_int(r0, 0x107, 0xa, &(0x7f000061f000)=0x2, 0x4)
setsockopt$packet_rx_ring(r0, 0x107, 0x5, &(0x7f0000c8b000)=@req3={0x10000, 0x3, 0x10000, 0x3, 0x4, 0xfffffffffffffffe, 0x5}, 0x1c)
And here’s one of the KASAN reports. It should be noted, that since the access is quite far past the block bounds, allocation and deallocation stacks don’t correspond to the overflown object.
==================================================================BUG: KASAN: slab-out-of-bounds in prb_close_block net/packet/af_packet.c:808Write of size 4 at addr ffff880054b70010 by task syz-executor0/30839
CPU: 0 PID: 30839 Comm: syz-executor0 Not tainted 4.11.0-rc2+ #94Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x292/0x398 lib/dump_stack.c:52 print_address_description+0x73/0x280 mm/kasan/report.c:246 kasan_report_error mm/kasan/report.c:345 [inline] kasan_report.part.3+0x21f/0x310 mm/kasan/report.c:368 kasan_report mm/kasan/report.c:393 [inline] __asan_report_store4_noabort+0x2c/0x30 mm/kasan/report.c:393 prb_close_block net/packet/af_packet.c:808 [inline] prb_retire_current_block+0x6ed/0x820 net/packet/af_packet.c:970 __packet_lookup_frame_in_block net/packet/af_packet.c:1093 [inline] packet_current_rx_frame net/packet/af_packet.c:1122 [inline] tpacket_rcv+0x9c1/0x3750 net/packet/af_packet.c:2236 packet_rcv_fanout+0x527/0x810 net/packet/af_packet.c:1493 deliver_skb net/core/dev.c:1834 [inline] __netif_receive_skb_core+0x1cff/0x3400 net/core/dev.c:4117 __netif_receive_skb+0x2a/0x170 net/core/dev.c:4244 netif_receive_skb_internal+0x1d6/0x430 net/core/dev.c:4272 netif_receive_skb+0xae/0x3b0 net/core/dev.c:4296 tun_rx_batched.isra.39+0x5e5/0x8c0 drivers/net/tun.c:1155 tun_get_user+0x100d/0x2e20 drivers/net/tun.c:1327 tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1353 call_write_iter include/linux/fs.h:1733 [inline] new_sync_write fs/read_write.c:497 [inline] __vfs_write+0x483/0x760 fs/read_write.c:510 vfs_write+0x187/0x530 fs/read_write.c:558 SYSC_write fs/read_write.c:605 [inline] SyS_write+0xfb/0x230 fs/read_write.c:597 entry_SYSCALL_64_fastpath+0x1f/0xc2RIP: 0033:0x40b031RSP: 002b:00007faacbc3cb50 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 000000000000002a RCX: 000000000040b031RDX: 000000000000002a RSI: 0000000020002fd6 RDI: 0000000000000015RBP: 00000000006e2960 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000708000R13: 000000000000002a R14: 0000000020002fd6 R15: 0000000000000000
Allocated by task 30534: save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:513 set_track mm/kasan/kasan.c:525 [inline] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555 slab_post_alloc_hook mm/slab.h:456 [inline] slab_alloc_node mm/slub.c:2720 [inline] slab_alloc mm/slub.c:2728 [inline] kmem_cache_alloc+0x1af/0x250 mm/slub.c:2733 getname_flags+0xcb/0x580 fs/namei.c:137 getname+0x19/0x20 fs/namei.c:208 do_sys_open+0x2ff/0x720 fs/open.c:1045 SYSC_open fs/open.c:1069 [inline] SyS_open+0x2d/0x40 fs/open.c:1064 entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed by task 30534: save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:513 set_track mm/kasan/kasan.c:525 [inline] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590 slab_free_hook mm/slub.c:1358 [inline] slab_free_freelist_hook mm/slub.c:1381 [inline] slab_free mm/slub.c:2963 [inline] kmem_cache_free+0xb5/0x2d0 mm/slub.c:2985 putname+0xee/0x130 fs/namei.c:257 do_sys_open+0x336/0x720 fs/open.c:1060 SYSC_open fs/open.c:1069 [inline] SyS_open+0x2d/0x40 fs/open.c:1064 entry_SYSCALL_64_fastpath+0x1f/0xc2
Object at ffff880054b70040 belongs to cache names_cache of size 4096The buggy address belongs to the page:page:ffffea000152dc00 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0flags: 0x500000000008100(slab|head)raw: 0500000000008100 0000000000000000 0000000000000000 0000000100070007raw: ffffea0001549a20 ffffea0001b3cc20 ffff88003eb44f40 0000000000000000page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff880054b6ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff880054b6ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff880054b70000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb                         ^ ffff880054b70080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff880054b70100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb==================================================================
You can find more details about syzkaller in it’s repository and more details about KASAN in the kernel documentation. If you decide to try syzkaller or KASAN and run into any troubles drop an email to syzkaller@googlegroups.com or to kasan-dev@googlegroups.com.Introduction to AF_PACKET sockets
To better understand the bug, the vulnerability it leads to and how to exploit it, we need to understand what AF_PACKET sockets are and how they are implemented in the kernel.
AF_PACKET sockets allow users to send or receive packets on the device driver level. This for example lets them to implement their own protocol on top of the physical layer or to sniff packets including Ethernet and higher levels protocol headers. To create an AF_PACKET socket a process must have the CAP_NET_RAW capability in the user namespace that governs its network namespace. More details can be found in the packet sockets documentation. It should be noted that if a kernel has unprivileged user namespaces enabled, then an unprivileged user is able to create packet sockets.
To send and receive packets on a packet socket, a process can use the send and recv syscalls. However, packet sockets provide a way to do this faster by using a ring buffer, that’s shared between the kernel and the userspace. A ring buffer can be created via the PACKET_TX_RING and PACKET_RX_RING socket options. The ring buffer can then be mmaped by the user and the packet data can then be read or written directly to it.
There are a few different variants of the way the ring buffer is handled by the kernel. This variant can be chosen by the user by using the PACKET_VERSION socket option. The difference between ring buffer versions can be found in the kernel documentation (search for “TPACKET versions”).
One of the widely known users of AF_PACKET sockets is the tcpdump utility. This is roughly what happens when tcpdump is used to sniff all packets on a particular interface:
# strace tcpdump -i eth0...socket(PF_PACKET, SOCK_RAW, 768)        = 3...bind(3, {sa_family=AF_PACKET, proto=0x03, if2, pkttype=PACKET_HOST, addr(0)={0, }, 20) = 0...setsockopt(3, SOL_PACKET, PACKET_VERSION, [1], 4) = 0...setsockopt(3, SOL_PACKET, PACKET_RX_RING, {block_size=131072, block_nr=31, frame_size=65616, frame_nr=31}, 16) = 0...mmap(NULL, 4063232, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7f73a6817000...
This sequence of syscalls corresponds to the following actions:
  1. A socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) is created.
  2. The socket is bound to the eth0 interface.
  3. Ring buffer version is set to TPACKET_V2 via the PACKET_VERSION socket option.
  4. A ring buffer is created via the PACKET_RX_RING socket option.
  5. The ring buffer is mmapped in the userspace.

After that the kernel will start putting all packets coming through the eth0 interface in the ring buffer and tcpdump will read them from the mmapped region in the userspace.

Ring buffers
Let’s see how to use ring buffers for packet sockets. For consistency all of the kernel code snippets below will come from the Linux kernel 4.8. This is the version the latest Ubuntu 16.04.2 kernel is based on.
The existing documentation mostly focuses on TPACKET_V1 and TPACKET_V2 ring buffer versions. Since the mentioned bug only affects the TPACKET_V3 version, I’m going to assume that we deal with that particular version for the rest of the post. Also I’m going to mostly focus on PACKET_RX_RING ignoring PACKET_TX_RING.
A ring buffer is a memory region used to store packets. Each packet is stored in a separate frame. Frames are grouped into blocks. In TPACKET_V3 ring buffers frame size is not fixed and can have arbitrary value as long as a frame fits into a block.
To create a TPACKET_V3 ring buffer via the PACKET_RX_RING socket option a user must provide the exact parameters for the ring buffer. These parameters are passed to the setsockopt call via a pointer to a request struct called tpacket_req3, which is defined as:
274 struct tpacket_req3 {275         unsigned int    tp_block_size;  /* Minimal size of contiguous block */276         unsigned int    tp_block_nr;    /* Number of blocks */277         unsigned int    tp_frame_size;  /* Size of frame */278         unsigned int    tp_frame_nr;    /* Total number of frames */279         unsigned int    tp_retire_blk_tov; /* timeout in msecs */280         unsigned int    tp_sizeof_priv; /* offset to private data area */281         unsigned int    tp_feature_req_word;282 };
Here’s what each field means in the tpacket_req3 struct:
  1. tp_block_size - the size of each block.
  2. tp_block_nr - the number of blocks.
  3. tp_frame_size - the size of each frame, ignored for TPACKET_V3.
  4. tp_frame_nr - the number of frames, ignored for TPACKET_V3.
  5. tp_retire_blk_tov - timeout after which a block is retired, even if it’s not fully filled with data (see below).
  6. tp_sizeof_priv - the size of per-block private area. This area can be used by a user to store arbitrary information associated with each block.
  7. tp_feature_req_word - a set of flags (actually just one at the moment), which allows to enable some additional functionality.

Each block has an associated header, which is stored at the very beginning of the memory area allocated for the block. The block header struct is called tpacket_block_desc and has a block_status field, which indicates whether the block is currently being used by the kernel or available to the user. The usual workflow is that the kernel stores packets into a block until it’s full and then sets block_status to TP_STATUS_USER. The user then reads required data from the block and releases it back to the kernel by setting block_status to TP_STATUS_KERNEL.
186 struct tpacket_hdr_v1 {187         __u32   block_status;188         __u32   num_pkts;189         __u32   offset_to_first_pkt;...233 };234 235 union tpacket_bd_header_u {236         struct tpacket_hdr_v1 bh1;237 };238 239 struct tpacket_block_desc {240         __u32 version;241         __u32 offset_to_priv;242         union tpacket_bd_header_u hdr;243 };
Each frame also has an associated header described by the struct tpacket3_hdr. The tp_next_offset field points to the next frame within the same block.
162 struct tpacket3_hdr {163         __u32 tp_next_offset;...176 };
When a block is fully filled with data (a new packet doesn’t fit into the remaining space), it’s closed and released to userspace or “retired” by the kernel. Since the user usually wants to see packets as soon as possible, the kernel can release a block even if it’s not filled with data completely. This is done by setting up a timer that retires current block with a timeout controlled by the tp_retire_blk_tov parameter.
There’s also a way so specify per-block private area, which the kernel won’t touch and the user can use to store any information associated with a block. The size of this area is passed via the tp_sizeof_priv parameter.
If you’d like to better understand how a userspace program can use TPACKET_V3 ring buffer you can read the example provided in the documentation (search for “TPACKET_V3 example“).

Implementation of AF_PACKET sockets
Let’s take a quick look at how some of this is implemented in the kernel.
Struct definitions
Whenever a packet socket is created, an associated packet_sock struct is allocated in the kernel:
103 struct packet_sock {...105         struct sock             sk;...108         struct packet_ring_buffer       rx_ring;109         struct packet_ring_buffer       tx_ring;...123         enum tpacket_versions   tp_version;...130         int                     (*xmit)(struct sk_buff *skb);...132 };
The tp_version field in this struct holds the ring buffer version, which in our case is set to TPACKET_V3 by a PACKET_VERSION setsockopt call. The rx_ring and tx_ring fields describe the receive and transmit ring buffers in case they are created via PACKET_RX_RING and PACKET_TX_RING setsockopt calls. These two fields have type packet_ring_buffer, which is defined as:
56 struct packet_ring_buffer {57         struct pgv              *pg_vec;...70         struct tpacket_kbdq_core        prb_bdqc;71 };
The pg_vec field is a pointer to an array of pgv structs, each of which holds a reference to a block. Blocks are actually allocated separately, not as a one contiguous memory region.
52 struct pgv {53         char *buffer;54 };

The prb_bdqc field is of type tpacket_kbdq_core and its fields describe the current state of the ring buffer:
14 struct tpacket_kbdq_core {...21         unsigned short  blk_sizeof_priv;...36         char            *nxt_offset;...49         struct timer_list retire_blk_timer;50 };
The blk_sizeof_priv fields contains the size of the per-block private area. The nxt_offset field points inside the currently active block and shows where the next packet should be saved. The retire_blk_timer field has type timer_list and describes the timer which retires current block on timeout.
12 struct timer_list {...17         struct hlist_node       entry;18         unsigned long           expires;19         void                    (*function)(unsigned long);20         unsigned long           data;...31 };
Ring buffer setup
The kernel uses the packet_setsockopt() function to handle setting socket options for packet sockets. When the PACKET_VERSION socket option is used, the kernel sets po->tp_version to the provided value.
With the PACKET_RX_RING socket option a receive ring buffer is created. Internally it’s done by the packet_set_ring() function. This function does a lot of things, so I’ll just show the important parts. First, packet_set_ring() performs a bunch of sanity checks on the provided ring buffer parameters:
4202                 err = -EINVAL;4203                 if (unlikely((int)req->tp_block_size <= 0))4204                         goto out;4205                 if (unlikely(!PAGE_ALIGNED(req->tp_block_size)))4206                         goto out;4207                 if (po->tp_version >= TPACKET_V3 &&4208                     (int)(req->tp_block_size -4209                           BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv)) <= 0)4210                         goto out;4211                 if (unlikely(req->tp_frame_size < po->tp_hdrlen +4212                                         po->tp_reserve))4213                         goto out;4214                 if (unlikely(req->tp_frame_size & (TPACKET_ALIGNMENT - 1)))4215                         goto out;4216 4217                 rb->frames_per_block = req->tp_block_size / req->tp_frame_size;4218                 if (unlikely(rb->frames_per_block == 0))4219                         goto out;4220                 if (unlikely((rb->frames_per_block * req->tp_block_nr) !=4221                                         req->tp_frame_nr))4222                         goto out;
Then, it allocates the ring buffer blocks:
4224                 err = -ENOMEM;4225                 order = get_order(req->tp_block_size);4226                 pg_vec = alloc_pg_vec(req, order);4227                 if (unlikely(!pg_vec))4228                         goto out;
It should be noted that alloc_pg_vec() uses the kernel page allocator to allocate blocks (we’ll use this in the exploit):
4104 static char *alloc_one_pg_vec_page(unsigned long order)4105 {...4110         buffer = (char *) __get_free_pages(gfp_flags, order);4111         if (buffer)4112                 return buffer;...4127 }4128 4129 static struct pgv *alloc_pg_vec(struct tpacket_req *req, int order)4130 {...4139         for (i = 0; i < block_nr; i++) {4140                 pg_vec[i].buffer = alloc_one_pg_vec_page(order);...4143         }...4152 }
Finally, packet_set_ring() calls init_prb_bdqc(), which performs some additional steps to set up a TPACKET_V3 receive ring buffer specifically:
4229                 switch (po->tp_version) {4230                 case TPACKET_V3:...4234                         if (!tx_ring)4235                                 init_prb_bdqc(po, rb, pg_vec, req_u);4236                         break;4237                 default:4238                         break;4239                 }
The init_prb_bdqc() function copies provided ring buffer parameters to the prb_bdqc field of the ring buffer struct, calculates some other parameters based on them, sets up the block retire timer and calls prb_open_block() to initialize the first block:
604 static void init_prb_bdqc(struct packet_sock *po,605                         struct packet_ring_buffer *rb,606                         struct pgv *pg_vec,607                         union tpacket_req_u *req_u)608 {609         struct tpacket_kbdq_core *p1 = GET_PBDQC_FROM_RB(rb);610         struct tpacket_block_desc *pbd;...616         pbd = (struct tpacket_block_desc *)pg_vec[0].buffer;617         p1->pkblk_start = pg_vec[0].buffer;618         p1->kblk_size = req_u->req3.tp_block_size;...630         p1->blk_sizeof_priv = req_u->req3.tp_sizeof_priv;631 632         p1->max_frame_len = p1->kblk_size - BLK_PLUS_PRIV(p1->blk_sizeof_priv);633         prb_init_ft_ops(p1, req_u);634         prb_setup_retire_blk_timer(po);635         prb_open_block(p1, pbd);636 }
On of the things that the prb_open_block() function does is it sets the nxt_offset field of the tpacket_kbdq_core struct to point right after the per-block private area:
841 static void prb_open_block(struct tpacket_kbdq_core *pkc1,842         struct tpacket_block_desc *pbd1)843 {...862         pkc1->pkblk_start = (char *)pbd1;863         pkc1->nxt_offset = pkc1->pkblk_start + BLK_PLUS_PRIV(pkc1->blk_sizeof_priv);...876 }
Packet reception
Whenever a new packet is received, the kernel is supposed to save it into the ring buffer. The key function here is __packet_lookup_frame_in_block(), which does the following:
  1. Checks whether the currently active block has enough space for the packet.
  2. If yes, saves the packet to the current block and returns.
  3. If no, dispatches the next block and saves the packet there.

1041 static void *__packet_lookup_frame_in_block(struct packet_sock *po,1042                                             struct sk_buff *skb,1043                                                 int status,1044                                             unsigned int len1045                                             )1046 {1047         struct tpacket_kbdq_core *pkc;1048         struct tpacket_block_desc *pbd;1049         char *curr, *end;1050 1051         pkc = GET_PBDQC_FROM_RB(&po->rx_ring);1052         pbd = GET_CURR_PBLOCK_DESC_FROM_CORE(pkc);...1075         curr = pkc->nxt_offset;1076         pkc->skb = skb;1077         end = (char *)pbd + pkc->kblk_size;1078 1079         /* first try the current block */1080         if (curr+TOTAL_PKT_LEN_INCL_ALIGN(len) < end) {1081                 prb_fill_curr_block(curr, pkc, pbd, len);1082                 return (void *)curr;1083         }1084 1085         /* Ok, close the current block */1086         prb_retire_current_block(pkc, po, 0);1087 1088         /* Now, try to dispatch the next block */1089         curr = (char *)prb_dispatch_next_block(pkc, po);1090         if (curr) {1091                 pbd = GET_CURR_PBLOCK_DESC_FROM_CORE(pkc);1092                 prb_fill_curr_block(curr, pkc, pbd, len);1093                 return (void *)curr;1094         }...1101 }Vulnerability
Let’s look closely at the following check from packet_set_ring():
4207                 if (po->tp_version >= TPACKET_V3 &&4208                     (int)(req->tp_block_size -4209                           BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv)) <= 0)4210                         goto out;
This is supposed to ensure that the length of the block header together with the per-block private data is not bigger than the size of the block. Which totally makes sense, otherwise we won’t have enough space in the block for them let alone the packet data.
However turns out this check can be bypassed. In case req_u->req3.tp_sizeof_priv has the higher bit set, casting the expression to int results in a big positive value instead of negative. To illustrate this behavior:
A = req->tp_block_size = 4096 = 0x1000B = req_u->req3.tp_sizeof_priv = (1 << 31) + 4096 = 0x80001000BLK_PLUS_PRIV(B) = (1 << 31) + 4096 + 48 = 0x80001030A - BLK_PLUS_PRIV(B) = 0x1000 - 0x80001030 = 0x7fffffd0(int)0x7fffffd0 = 0x7fffffd0 > 0
Later, when req_u->req3.tp_sizeof_priv is copied to p1->blk_sizeof_priv in init_prb_bdqc() (see the snippet above), it’s clamped to two lower bytes, since the type of the latter is unsigned short. So this bug basically allows us to set the blk_sizeof_priv of the tpacket_kbdq_core struct to arbitrary value bypassing all sanity checks.
If we search through the net/packet/af_packet.c source looking for blk_sizeof_priv usage, we’ll find that it’s being used in the two following places.
The first one is in init_prb_bdqc() right after it gets assigned (see the code snippet above) to set max_frame_len. The value of p1->max_frame_len denotes the maximum size of a frame that can be saved into a block. Since we control p1->blk_sizeof_priv, we can make BLK_PLUS_PRIV(p1->blk_sizeof_priv) bigger than p1->kblk_size. This will result in p1->max_frame_len having a huge value, higher than the size of a block. This allows us to bypass the size check when a frame is being copied into a block, thus causing a kernel heap out-of-bounds write.
That’s not all. Another user of blk_sizeof_priv is prb_open_block(), which initializes a block (the code snippet is above as well). There pkc1->nxt_offset denotes the address, where the kernel will write a new packet when it’s being received. The kernel doesn’t intend to overwrite the block header and per-block private data, so it makes this address to point right after them. Since we control blk_sizeof_priv, we can control the lowest two bytes of nxt_offset. This allows us to control offset of the out-of-bounds write.
To sum up, this bug leads to a kernel heap out-of-bounds write of controlled maximum size and controlled offset up to about 64k bytes. Exploitation
Let’s see how we can exploit this vulnerability. I’m going to be targeting x86-64 Ubuntu 16.04.2 with 4.8.0-41-generic kernel version with KASLR, SMEP and SMAP enabled. Ubuntu kernel has user namespaces available to unprivileged users (CONFIG_USER_NS=y and no restrictions on it’s usage), so the bug can be exploited to gain root privileges by an unprivileged user. All of the exploitation steps below are performed from within a user namespace.
The Linux kernel has support for a few hardening features that make exploitation more difficult. KASLR (Kernel Address Space Layout Randomization) puts the kernel text at a random offset to make jumping to a particular fixed address useless. SMEP (Supervisor Mode Execution Protection) causes an oops whenever the kernel tries to execute code from the userspace memory and SMAP (Supervisor Mode Access Prevention) does the same whenever the kernel tries to access the userspace memory directly.
Shaping heap
The idea of the exploit is to use the heap out-of-bounds write to overwrite a function pointer in the memory adjacent to the overflown block. For that we need to specifically shape the heap, so some object with a triggerable function pointer is placed right after a ring buffer block. I chose the already mentioned packet_sock struct to be this object. We need to find a way to make the kernel allocate a ring buffer block and a packet_sock struct one next to the other.
As I mentioned above, ring buffer blocks are allocated with the kernel page allocator (buddy allocator). It allows to allocate blocks of 2^n contiguous memory pages. The allocator keeps a freelist of such block for each n and returns the freelist head when a block is requested. If the freelist for some n is empty, it finds the first m > n, for which the freelist is not empty and splits it in halves until the required size is reached. Therefore, if we start repeatedly allocating blocks of size 2^n, at some point they will start coming from one high order memory block being split and they will be adjacent each one to the next.
A packet_sock is allocated via the kmalloc() function by the slab allocator. The slab allocator is mostly used to allocate objects of a smaller-than-one-page size. It uses the page allocator to allocate a big block of memory and splits this block into smaller objects. The big blocks are called slabs, hence the name of the allocator. A set of slabs together with their current state and a set of operations like “allocate an object” and “free an object” is called a cache. The slab allocator creates a set of general purpose caches for objects of size 2^n. Whenever kmalloc(size) is called, the slab allocator rounds size up to the nearest power of 2 and uses the cache of that size.
Since the kernel uses kmalloc() all the time, if we try to allocate an object it will most likely come from one of the slabs already created during previous usage. However, if we start allocating objects of the same size, at some point the slab allocator will run out of slabs for this size and will have to allocate another one via the page allocator.
The size of a newly allocated slab depends on the size of objects this slab is meant for. The size of the packet_sock struct is ~1920 and 1024 < 1920 <= 2048, which means that it’ll be rounded to 2048 and the kmalloc-2048 cache will be used. Turns out, for this particular cache the SLUB allocator (which is the kind of slab allocator used in Ubuntu) uses slabs of size 0x8000. So whenever the allocator runs out of slabs for the kmalloc-2048 cache, it allocates 0x8000 bytes with the page allocator.
Keeping all that in mind, this is how we can allocate a kmalloc-2048 slab next to a ring buffer block:
  1. Allocate a lot (512 worked for me) of objects of size 2048 to fill currently existing slabs in the kmalloc-2048 cache. To do that we can create a bunch of packet sockets to cause allocation of packet_sock structs.
  2. Allocate a lot (1024 worked for me) page blocks of size 0x8000 to drain the page allocator freelists and cause some high-order page block to be split. To do that we can create another packet socket and attach a ring buffer with 1024 blocks of size 0x8000.
  3. Create a packet socket and attach a ring buffer with blocks of size 0x8000. The last one of these blocks (I’m using 2 blocks, the reason is explained below) is the one we’re going to overflow.
  4. Create a bunch of packet sockets to allocate packet_sock structs and cause an allocation of at least one new slab.
This way we can shape the heap in the following way:

The exact number of allocations to drain freelists and shape the heap the way we want might be different for different setups and depend on the memory usage activity. The numbers above are for a mostly idle Ubuntu machine.
Controlling the overwrite
Above I explained that the bug results in a write of a controlled maximum size at a controlled offset out of the bounds of a ring buffer block. Turns out not only we can control the maximum size and offset, we can actually control the exact data (and it’s size) that’s being written. Since the data that’s being stored in a ring buffer block is the packet that’s passing through a particular network interface, we can manually send packets with arbitrary content on a raw socket through the loopback interface. If we’re doing that in an isolated network namespace no external traffic will interfere.
There are a few caveats though.
First, it seems that the size of a packet must be at least 14 bytes (12 bytes for two mac addresses and 2 bytes for the EtherType apparently) for it to be passed to the packet socket layer. That means that we have to overwrite at least 14 bytes. The data in the packet itself can be arbitrary.
Then, the lowest 3 bits of nxt_offset always have the value of 2 due to the alignment. That means that we can’t start overwriting at an 8-byte aligned offset.
Besides that, when a packet is being received and saved into a block, the kernel updates some fields in the block and frame headers. If we point nxt_offset to some particular offset we want to overwrite, some data where the block and frames headers end up will probably be corrupted.
Another issue is that if we make nxt_offset point past the block end, the first block will be immediately closed when the first packet is being received, since the kernel will (correctly) decide that there’s no space left in the first block (see the __packet_lookup_frame_in_block() snippet). This is not really an issue, since we can create a ring buffer with 2 blocks. The first one will be closed, the second one will be overflown.
Executing code
Now, we need to figure out which function pointers to overwrite. There are a few of function pointers fields in the packet_sock struct, but I ended up using the following two:
  1. packet_sock->xmit
  2. packet_sock->rx_ring->prb_bdqc->retire_blk_timer->func

The first one is called whenever a user tries to send a packet via a packet socket. The usual way to elevate privileges to root is to execute the commit_creds(prepare_kernel_cred(0)) payload in a process context. The xmit pointer is called from a process context, which means we can simply point it to the executable memory region, which contains the payload.
To do that we need to put our payload to some executable memory region. One of the possible ways for that is to put the payload in the userspace, either by mmapping an executable memory page or by just defining a global function within our exploit program. However, SMEP & SMAP will prevent the kernel from accessing and executing user memory directly, so we need to deal with them first.
For that I used the retire_blk_timer field (the same field used by Philip Pettersson in his CVE-2016-8655 exploit). It contains a function pointer that’s triggered whenever the retire timer times out. During normal packet socket operation, retire_blk_timer->func points to prb_retire_rx_blk_timer_expired() and it’s called with retire_blk_timer->data as an argument, which contains the address of the packet_sock struct. Since we can overwrite the data field along with the func field, we get a very nice func(data) primitive.
The state of SMEP & SMAP on the current CPU core is controlled by the 20th and 21st bits of the CR4 register. To disable them we should zero out these two bits. For this we can use the func(data) primitive to call native_write_cr4(X), where X has 20th and 21st bits set to 0. The exact value of X might depend on what other CPU features are enabled. On the machine where I tested the exploit, the value of CR4 is 0x10407f0 (only the SMEP bit is enabled since the CPU has no SMAP support), so I used X = 0x407f0. We can use the sched_setaffinity syscall to force the exploit program to be executed on one CPU core and thus making sure that the userspace payload will be executed on the same core as where we disable SMAP & SMEP.
Putting this all together, here are the exploitation steps:
  1. Figure out the kernel text address to bypass KASLR (described below).
  2. Pad heap as described above.
  3. Disable SMEP & SMAP.
    1. Allocate a packet_sock after a ring buffer block.
    2. Schedule a block retire timer on the packet_sock by attaching a receive ring buffer to it.
    3. Overflow the block and overwrite retire_blk_timer field. Make retire_blk_timer->func point to native_write_cr4 and make retire_blk_timer->data equal to the desired CR4 value.
    4. Wait for the timer to be executed, now we have SMEP & SMAP disabled on the current core.
  4. Get root privileges.
    1. Allocate another pair of a packet_sock and a ring buffer block.
    2. Overflow the block and overwrite xmit field. Make xmit point to a commit_creds(prepare_kernel_cred(0)) allocated in userspace.
    3. Send a packet on the corresponding packet socket, xmit will get triggered and the current process will obtain root privileges.

The exploit code can be found here.
It should be noted, that when we overwrite these two fields in the packet_sock structs, we’ll end up corrupting some of the fields before them (the kernel will write some values to the block and frame headers), which can lead to a kernel crash. However, as long as these other fields don’t get used by the kernel we should be good. I found that one of the fields that caused crashes if we try to close all packet sockets after the exploit finished is the mclist field, but simply zeroing it out helps.

KASLR bypass
I didn’t bother to come up with some elaborate KASLR bypass technique which exploits the same bug. Since Ubuntu doesn’t restrict dmesg by default, we can just grep the kernel syslog for the “Freeing SMP” string, which contains a kernel pointer, that looks suspiciously similar to the kernel text address:
# Boot #1$ dmesg | grep 'Freeing SMP'[    0.012520] Freeing SMP alternatives memory: 32K (ffffffffa58ee000 - ffffffffa58f6000)$ sudo cat /proc/kallsyms | grep 'T _text'ffffffffa4800000 T _text
# Boot #2$ dmesg | grep 'Freeing SMP'[    0.017487] Freeing SMP alternatives memory: 32K (ffffffff85aee000 - ffffffff85af6000)$ sudo cat /proc/kallsyms | grep 'T _text'ffffffff84a00000 T _text
By doing simple math we can calculate the kernel text address based on the one exposed through dmesg. This way of figuring out the kernel text location works only for some time after boot, as syslog only stores a fixed number of lines and starts dropping them at some point.
There are a few Linux kernel hardening features that can be used to prevent this kind of information disclosures. The first one is called dmesg_restrict and it restricts the ability of unprivileged users to read the kernel syslog. It should be noted, that even with dmesg restricted the first user on Ubuntu can still read the syslog from /var/log/kern.log and /var/log/syslog since he belongs to the adm group.
Another feature is called kptr_restrict and it doesn’t allow unprivileged users to see pointers printed by the kernel with the %pK format specifier. However in 4.8 the free_reserved_area() function uses %p, so kptr_restrict doesn’t help in this case. In 4.10 free_reserved_area() was fixed not to print address ranges at all, but the change was not backported to older kernels.
Let’s take a look at the fix. The vulnerable code as it was before the fix is below. Remember that the user fully controls both tp_block_size and tp_sizeof_priv.
4207                 if (po->tp_version >= TPACKET_V3 &&4208                     (int)(req->tp_block_size -4209                           BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv)) <= 0)4210                         goto out;
When thinking about a way to fix this, the first idea that comes to mind is that we can compare the two values as is without that weird conversion to int:
4207                 if (po->tp_version >= TPACKET_V3 &&4208                     req->tp_block_size <=4209                           BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv))4210                         goto out;
Funny enough, this doesn’t actually help. The reason is that an overflow can happen while evaluating BLK_PLUS_PRIV in case tp_sizeof_priv is close to the unsigned int maximum value.
177 #define BLK_PLUS_PRIV(sz_of_priv) \178         (BLK_HDR_LEN + ALIGN((sz_of_priv), V3_ALIGNMENT))
One of the ways to fix this overflow is to cast tp_sizeof_priv to uint64 before passing it to BLK_PLUS_PRIV. That’s exactly what I did in the fix that was sent upstream.
4207                 if (po->tp_version >= TPACKET_V3 &&4208                     req->tp_block_size <=4209                           BLK_PLUS_PRIV((u64)req_u->req3.tp_sizeof_priv))4210                         goto out;Mitigation
Creating packet socket requires the CAP_NET_RAW privilege, which can be acquired by an unprivileged user inside a user namespaces. Unprivileged user namespaces expose a huge kernel attack surface, which resulted in quite a few exploitable vulnerabilities (CVE-2017-7184, CVE-2016-8655, ...). This kind of kernel vulnerabilities can be mitigated by completely disabling user namespaces or disallowing using them to unprivileged users.
To disable user namespaces completely you can rebuild your kernel with CONFIG_USER_NS disabled. Restricting user namespaces usage only to privileged users can be done by writing 0 to /proc/sys/kernel/unprivileged_userns_clone in Debian-based kernel. Since version 4.9 the upstream kernel has a similar /proc/sys/user/max_user_namespaces setting.Conclusion
Right now the Linux kernel has a huge number of poorly tested (from a security standpoint) interfaces and a lot of them are enabled and exposed to unprivileged users in popular Linux distributions like Ubuntu. This is obviously not good and they need to be tested or restricted.
Syzkaller is an amazing tool that allows to test kernel interfaces via fuzzing. Even adding barebone descriptions for another syscall usually uncovers numbers of bugs. We certainly need people writing syscall descriptions and fixing existing ones, since there’s a huge surface that’s still not covered and probably a ton of security bugs buried in the kernel. If you decide to contribute, we’ll be glad to see a pull request.Links
Just a bunch of related links.
Exploit: https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-7308Fix: https://github.com/torvalds/linux/commit/2b6867c2ce76c596676bec7d2d525af525fdc6e2CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7308
Our Linux kernel bug finding tools:
A collection of Linux kernel exploitation materials: https://github.com/xairy/linux-kernel-exploitation
Categories: Security


Subscribe to www.hdgonline.net aggregator