Feed aggregator

In the news

iPhone J.D. - Fri, 10/12/2018 - 00:50

I was talking to an attorney this week about buying a new iPad, and I'll tell you the same thing I told him:  don't.  At least, not right now.  All signs are that Apple will introduce two new models of the iPad Pro in the next few weeks, and perhaps a second generation version of the Apple Pencil — which part of me hopes Apple will call the "No. 2 Pencil."  The speculation is that it will support Face ID, have smaller bezels, and perhaps even use USB-C instead of Lightning.  We'll see.  And now, the news of note from the past week:

  • Virginia attorney Sharon Nelson discusses a recent incident in which the FBI compelled an iPhone owner (via a warrant) to unlock his iPhone using Face ID.
  • Nelson also discusses an incident in which police arrested someone for murder based on data from the victim's Fitbit — and it could have just as easily been an Apple Watch.  Her heart rate spiked, and then ceased to register at all, during the time that video surveillance showed that her stepfather was in her house.
  • California attorney David Sparks discusses Apple's announcement yesterday that 53% of users of iOS devices sold in the last four years have already updated to iOS 12.  Once iOS 12.1 comes out with the new Emoji I discussed earlier this year, I'm sure even more folks will rush to upgrade.
  • Speak of Sparks, yesterday I recommended his video field guide on using the Shortcuts app, and I also see that this week he experimented with replacing all of the icons on his iPhone's home screen with Siri shortcuts.  Interesting.
  • If you are looking for a place to find and download some interesting iPhone shortcuts, check out Sharecuts.app.
  • Don't be like Kanye West.  There are probably many ways one could apply that rule, but right now I'm referring to his Oval Office meeting with President Trump yesterday morning in which Kanye entered his iPhone passcode while a camera was filming him from behind — his first no-no — and then the entire world saw that Kanye's password is 000000, i.e. just six zeros.  Chance Miller of 9to5Mac has the details including a video clip.  Seriously, don't do that.
  • Speaking of iPhone security, Glenn Fleishman of TidBITS explains how two-factor authentication is improved in iOS 12, and also explains why you should try not to use SMS (text messaging) as a second factor.
  • As I noted above, the next version of the iPad Pro might have USB-C.  In an article for Macworld, Jason Snell analyzes what that could mean for users.
  • Zac Hall of 9to5Mac wrote a great overview of the types of HomeKit accessories that you can use to control your home with Siri, and he even recommends some of the best specific brands.  I continue to be a huge fan of the Lutron switches in my house, which I reviewed in 2015
  • Bryan Wolfe of the iDownloadBlog explains how to use the Live Listen feature of iOS 12.  Place your iPhone close to a source of sound, put on your AirPods, and then your iPhone will act as a remote microphone for your AirPods.  Useful if you need to hear something or someone but you are too far away to do so.
  • One of my favorite features of Apple Music is the ability to request a song by part of a lyric — Hey Siri, play the song that goes [say a few words in the lyrics].  Benjamin Mayo of 9to5Mac reports that this function will improve because Apple is now incorporating more lyrics from a company called Genius.
  • There was a horrible story in the news this week about a reporter who wrote for the Washington Post being killed while in the Saudi consulate in Turkey.  Reuters reports that information gained from the Apple Watch he was wearing might help the investigators to figure out what happened.
  • Here is a useful page on the Apple website which describes each of the status icons and symbols on the Apple Watch.
  • Security expert Rich Mogull happens to also be a paramedic, and in an article for TidBITS, he describes how the Apple Watch Series 4 may (and may not) help to save lives.
  • Matthew Cassinelli of The Sweet Setup explains why the 1Password app is so useful on an Apple Watch.  I agree.
  • Jesse Hollington of iLounge reports that today Apple is debuting Season 2 of Carpool Karaoke, including one episode featuring the Muppets.  It's time to play the music, it's time to light the lights...
  • And finally, here is a video from Apple showing off some of the new features of the iPhone XS and XR.  That's one reason to watch the video, but another reason is that it does a great job of showing off Apple's new Apple Park campus:

Categories: iPhone Web Sites

Review: Siri Shortcuts Field Guide by David Sparks -- learn how to create useful shortcuts

iPhone J.D. - Thu, 10/11/2018 - 01:12

One of my favorite features in iOS 12 is the new Shortcuts app and its deep integration with iOS, allowing you to create all sorts of useful automations to be more productive on your iPhone and iPad.  There is a learning curve, and thus I'm sure that lots of iPhone users won't even bother to pay much attention to shortcuts.  But if you are smart enough to have made it through Con Law I and the Rule Against Perpetuities part of your 1L Property class, you are more than smart enough to use the Shortcuts app.  Even so, it helps to have a guide hold your hand while you get started.

California attorney David Sparks created what he calls a video field guide — a series of short video lessons, a total of 3 hours and 15 minutes — to walk you through the Shortcuts app.  The course is called the Siri Shortcuts Field Guide and costs $29, although it is currently discounted to $24 during the introductory period.  David gave me a free pass to the course so that I could check it out, and I'm super impressed.  Whether you are starting from square 1 or you have a general sense of how shortcuts work but want to learn more (which describes me), this is a fantastic resource.

You access the course in any web browser.  It was perfect to watch it on my iPad Pro, but you could also watch it on an iPhone or a computer if you prefer.

On the iPad, there is a list of chapters on the left.  I'm sure that David designed the course to go through each one in order, but instead I jumped around, skipping the chapters devoted to topics that I thought I already knew.  Sometimes I went back to watch that chapter anyway because I realized that I didn't know as much as I thought I knew.

The course does a great job of walking you through the Shortcuts app itself, and then it shows you how to do things with the app, including working with different types of information.  In each lesson, you see David's iPad screen as he is describing to you what he is doing.  There is a great interface for the videos; you can scroll your finger across the bottom to jump ahead or go back.

I particularly enjoyed the lesson in the Advanced Siri Shortcuts Tools section on creating and using variables.  Before this course, I had no idea what a Magic Variable was, but after watching David describe what they do and actually create a shortcut using Magic Variables, now it all makes perfect sense to me.

I think that the best part of the course is the last main section called Useful Shorcuts.  David walks you through 12 shortcuts that you might actually use, explaining how he created each one why he did what he did.  You can create the shortcuts on your own by following along with David, or you can just download the complete shortcut.

One such shortcut useful to lawyers is a date calculator.  The shortcut David created lets you count a certain number of days after a date or before a date, or even the number of days between dates.  For me, this is so useful that I even added a Siri command to it so that I can just say "Hey Siri, date calculator" to bring it up.  And now that I understand how the shortcut works, I can modify it to meet my particular needs.  Here is a very short video showing me using the date calculator shortcut that David describes and provides in the lesson:

Conclusion

If you have any interest in creating shortcuts to increase your efficiency and accomplish tasks, I highly recommend this video course.  And I especially recommend getting into this now.  What Apple has already done with the Shortcuts app is amazing, but I know that it will get more useful in future updates.  By getting your arms around this stuff now, you will be well-positioned to take advantage of the improvements to the Shortcuts app over the coming months and years.

Click here to get more information and to sign up for the Siri Shortcuts Field Guide.

Categories: iPhone Web Sites

Apple Watch tip: switch from grid view to list view

iPhone J.D. - Mon, 10/08/2018 - 23:49

The Apple Watch has supported third party apps since it was first went on sale on April 24, 2015.  Unfortunately, however, because of the limitations of the hardware and the software, usability has been limited.  Graham Bower of Cult of Mac wasn't very far off the mark when he wrote an article in 2016 titled "Apple Watch apps kinda suck, but Cupertino hopes you won’t notice." 

Fortunately, with the new Apple Watch Series 4 and watchOS 5, I think those days are over.  Third party apps which have complications on my watch face or which are stored in my dock now launch pretty much instantly.  And just as impressively, even third party apps which I use less often and need to access by pressing the Digital Crown to see all of my apps now launch almost instantly, often under a second.  Moreover, with the speed of the Apple Watch Series 4, performance is high enough that apps are much more responsive.  As a result, Apple Watch apps no longer "suck," and I'm sure that Cupertino is happy for you to notice that.

All of this means that I'm starting to download more apps for my Apple Watch.  Some are more useful than others, but at least now all third party apps have the ability to be really good. Just to name one example, PCalc is a great calculator on the iPhone, but it is also a very usable calculator on the Apple Watch — much better than the Casio Calculator Watch I wore back in the 1980s.

   
As I have downloaded more apps to my Apple Watch, there are more apps to choose from when I press the Digital Crown on the side of my watch.  To make it easier to find the app that I want, I'm now taking advantage of a feature that was introduced in watchOS 4 last year:  the ability to switch from grid view to list view.  Grid view with its honeycomb layout is pretty, but unless you remember exactly where you placed an app, you will waste time searching around the screen to find it.  In list view, everything is alphabetical, and it is quick and easy to spin the Digital Crown to scroll to the name of the app that you want — something which is made even easier with the haptic feedback added to the Digital Crown in the Apple Watch Series 4.  You can now feel it as you scroll past every app in the list.

   
To switch from one view to another, simply press the Digital Crown, and then regardless of whether you are currently in grid view or list view, force press on the center of the screen.  This brings up a screen with the option to select either grid or list view.

If you own an Apple Watch Series 4, I encourage you to enable the list view so that it is easier for you take advantage of third party apps, even if you don't use them very often.

Categories: iPhone Web Sites

IBM DS8880 Product Guide (Release 8.5)

IBM Redbooks Site - Mon, 10/08/2018 - 09:30
Draft Redpaper, last updated: Mon, 8 Oct 2018

This IBM Redbooks® Product Guide gives an overview of the features and functions that are available with the IBM DS8880 models running microcode Release 8.5 (DS8000 License Machine Code 8.8.50.xx.xx).

Categories: Technology

IBM DS8880 High-Performance Flash Enclosure Gen2

IBM Redbooks Site - Mon, 10/08/2018 - 09:30
Draft Redpaper, last updated: Mon, 8 Oct 2018

This IBM® Redpaper™ publication describes the High-Performance Enclosure (HPFE) Gen2 architecture and configuration.

Categories: Technology

In the news

iPhone J.D. - Fri, 10/05/2018 - 00:15

I posted my review of the Apple Watch Series 4 earlier this week, and so did many others.  I particularly enjoyed the reviews by Jason Snell of Six Colors and Zac Hall of 9to5Mac.  Michael Steeber of 9to5Mac writes about the new-and-improved Digital Crown on the Apple Watch Series 4.  Also notable was the review by Joann Stern of the Wall Street Journal because of the video which accompanies that review; she hired a stunt woman to test the fall detection feature.  Even if you don't read the review, you should watch the fun video so that you can see how fall detection works without having to fall down yourself.  And now, the news of note from the past week:

Categories: iPhone Web Sites

365 Days Later: Finding and Exploiting Safari Bugs using Publicly Available Tools

Google Project Zero - Thu, 10/04/2018 - 12:40
Posted by Ivan Fratric, Google Project Zero
Around a year ago, we published the results of research about the resilience of modern browsers against DOM fuzzing, a well-known technique for finding browser bugs. Together with the bug statistics we also published Domato, our DOM fuzzing tool that was used to find those bugs.
Given that in the previous research, Apple Safari, or more specifically, WebKit (its DOM engine) did noticeably worse than other browsers, we decided to revisit it after a year using exactly the same methodology and exactly the same tools to see whether anything changed.
Test Setup
As in the original research, the fuzzing was initially done against WebKitGTK+ and then all the crashes were tested against Apple Safari running on a Mac. This makes the fuzzing setup easier as WebKitGTK+ uses the same DOM engine as Safari, but allows for fuzzing on a regular Linux machine. In this research, WebKitGTK+ version 2.20.2 was used which can be downloaded here.
To improve the fuzzing process, a couple of custom changes were made to WebKitGTK+:
  • Made fixes to be able to build WebKitGTK+ with ASan (Address Sanitizer).

  • Changed window.alert() implementation to immediately call the garbage collector instead of displaying a message window. This works well because window.alert() is not something we would normally call during fuzzing.

  • Normally, when a DOM bug causes a crash, due to the multi-process nature of WebKit, only the web process would crash, but the main process would continue running. Code was added that monitors a web process and, if it crashes, the code would “crash” the main process with the same status.

  • Created a custom target binary.

After the previous research was published, we got a lot of questions about the details of our fuzzing setup. This is why, this time, we are publishing the changes made to the WebKitGTK+ code as well as the detailed build instructions below. A patch file can be found here. Note that the patch was made with WebKitGTK+ 2.20.2 and might not work as is on other versions.
Once WebKitGTK+ code was prepared, it was built with ASan by running the following commands from the WebKitGTK+ directory:
export CC=/usr/bin/clangexport CXX=/usr/bin/clang++export CFLAGS="-fsanitize=address"export CXXFLAGS="-fsanitize=address"export LDFLAGS="-fsanitize=address"export ASAN_OPTIONS="detect_leaks=0"
mkdir buildcd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=. -DCMAKE_SKIP_RPATH=ON -DPORT=GTK -DLIB_INSTALL_DIR=./lib -DUSE_LIBHYPHEN=OFF -DENABLE_MINIBROWSER=ON -DUSE_SYSTEM_MALLOC=ON -DENABLE_GEOLOCATION=OFF -DENABLE_GTKDOC=OFF -DENABLE_INTROSPECTION=OFF -DENABLE_OPENGL=OFF -DENABLE_ACCELERATED_2D_CANVAS=OFF -DENABLE_CREDENTIAL_STORAGE=OFF -DENABLE_GAMEPAD_DEPRECATED=OFF -DENABLE_MEDIA_STREAM=OFF -DENABLE_WEB_RTC=OFF -DENABLE_PLUGIN_PROCESS_GTK2=OFF -DENABLE_SPELLCHECK=OFF -DENABLE_VIDEO=OFF -DENABLE_WEB_AUDIO=OFF -DUSE_LIBNOTIFY=OFF -DENABLE_SUBTLE_CRYPTO=OFF -DUSE_WOFF2=OFF -Wno-dev ..
make -j 4
mkdir -p libexec/webkit2gtk-4.0cp bin/WebKit*Process libexec/webkit2gtk-4.0/
If you are doing this for the first time, the cmake/make step will likely complain about missing dependencies, which you will then have to install. You might note that a lot of features deemed not overly important for DOM fuzzing were disabled via -DENABLE flags. This was mainly to save us from having to install the corresponding dependencies but in some cases also to create a build that was more “portable”.
After the build completes, the fuzzing is as simple as creating a sample with Domato, running the target binary as
ASAN_OPTIONS=detect_leaks=0,exitcode=42 ASAN_SYMBOLIZER_PATH=/path/to/llvm-symbolizer LD_LIBRARY_PATH=./lib ./bin/webkitfuzz /path/to/sample <timeout>
and waiting for the exit code 42 (which, if you take a look at the command line above as well as the changes we made to the WebKitGTK+ code, indicates an ASan crash).
After collecting crashes, an ASan build of the most recent WebKit source code was created on the actual Mac hardware. This is as simple as running
./Tools/Scripts/set-webkit-configuration --release --asan./Tools/Scripts/build-webkit
Each crash obtained on WebKitGTK+ was tested against the Mac build before reporting to Apple.
The Results
After running the fuzzer for 100.000.000 iterations (the same as a year ago) I ended up with 9 unique bugs that were reported to Apple. Last year, I estimated that the computational power to perform this number of iterations could be purchased for about $1000 and this probably hasn’t changed - an amount well within the payment range of a wide range of attackers with varying motivation.
The bugs are summarized in the table below. Please note that all of the bugs have been fixed at the time of release of this blog post.
Project Zero bug IDCVETypeAffected Safari 11.1.2Older than 6 monthsOlder than 1 year1593CVE-2018-4197UAFYESYESNO1594CVE-2018-4318UAFNONONO1595CVE-2018-4317UAFNOYESNO1596CVE-2018-4314UAFYESYESNO1602CVE-2018-4306UAFYESYESNO1603CVE-2018-4312UAFNONONO1604CVE-2018-4315UAFYESYESNO1609CVE-2018-4323UAFYESYESNO1610CVE-2018-4328OOB readYESYESYESUAF = use-after-free. OOB = out-of-bounds
As can be seen in the table, out of the 9 bugs found, 6 affected the release version of Apple Safari, directly affecting Safari users.
While 9 or 6 bugs (depending how you count) is significantly less than the 17 found a year ago, it is still a respectable number of bugs, especially if we take into an account that the fuzzer has been public for a long time now.
After the results were in, I looked into how long these bugs have been in the WebKit codebase. To check this, all the bugs were tested against a version of WebKitGTK+ that was more than 6 months old (WebKitGTK+ 2.19.6) as well as a version that was more than a year old (WebKitGTK+ 2.16.6).
The results are interesting—most of the bugs were sitting in the WebKit codebase for longer than 6 months, however, only 1 of them is older than 1 year. Here, it might be important to note that throughout the past year (between the previous and this blog post) I also did fuzzing runs using the same approach and reported 14 bugs. Unfortunately, it is impossible to know how many of those 14 bugs would have survived until now and how many would have been found in this fuzz run. It is also possible that some of the newly found bugs are actually older, but don’t trigger with the provided PoCs is in the older versions due to unrelated code changes in the DOM. I didn’t investigate this possibility.
However, even if we assume that all of the previously reported bugs would not have survived until now, the results still indicate that (a) the security vulnerabilities keep getting introduced in the WebKit codebase and (b) many of those bugs get incorporated into the release products before they are caught by internal security efforts.
While (a) is not unusual for any piece of software that changes as rapidly as a DOM engine, (b) might indicate the need to put more computational resources into fuzzing and/or review before release.
The Exploit
To prove that bugs like this can indeed lead to a browser compromise, I decided to write an exploit for one of them. The goal was not to write a very reliable or sophisticated exploit - highly advanced attackers would likely not choose to use the bugs found by public tools whose lifetime is expected to be relatively short. However, if someone with exploit writing skills was to use such a bug in, for example, a malware spreading campaign, they could potentially do a lot of damage even with an unreliable exploit.
Out of the 6 issues affecting the release version of Safari, I selected what I believed to be the easiest one to exploit—a use-after-free where, unlike in the other use-after-free issues found, the freed object is not on the isolated heap—a mitigation recently introduced in WebKit to make use-after-free exploitation harder.
Let us first start by examining the bug we’re going to exploit. The issue is a use-after-free in the SVGAnimateElementBase::resetAnimatedType() function. If you look at the code of the function, you are going to see that, first, the function gets a raw pointer to the SVGAnimatedTypeAnimator object on the line
   SVGAnimatedTypeAnimator* animator = ensureAnimator();
and, towards the end of the function, the animator object is used to obtain a pointer to a SVGAnimatedType object (unless one already exists) on the line
   m_animatedType = animator->constructFromString(baseValue);
The problem is that, in between these two lines, attacker-controlled JavaScript code could run. Specifically, this could happen during a call to computeCSSPropertyValue(). The JavaScript code could then cause SVGAnimateElementBase::resetAnimatedPropertyType() to be called, which would delete the animator object. Thus, the constructFromString() function would be called on the freed animator object - a typical use-after-free scenario, at least on the first glance. There is a bit more to this bug though, but we’ll get to that later.
The vulnerability has been fixed in the latest Safari by no longer triggering JavaScript callbacks through computeCSSPropertyValue(). Instead, the event handler is going to be processed at some later time. The patch can be seen here.
A simple proof of concept for the vulnerability is:
<body onload="setTimeout(go, 100)">  <svg id="svg">    <animate id="animate" attributeName="fill" />  </svg>  <div id="inputParent" onfocusin="handler()">    <input id="input">  </div>  <script>    function handler() {      animate.setAttribute('attributeName','fill');    }    function go() {      input.autofocus = true;      inputParent.after(inputParent);      svg.setCurrentTime(1);    }  </script></body>
Here, svg.setCurrentTime() results in resetAnimatedType() being called, which in turn, due to DOM mutations made previously, causes a JavaScript event handler to be called. In the event handler, the animator object is deleted by resetting the attributeName attribute of the animate element.
Since constructFromString() is a virtual method of the SVGAnimatedType class, the primitive the vulnerability gives us is a virtual method call on a freed object.
In the days before ASLR, such a vulnerability would be immediately exploitable by replacing the freed object with data we control and faking the virtual method table of the freed object, so that when the virtual method is called, execution is redirected to the attacker’s ROP chain. But due to ASLR we won’t know the addresses of any executable modules in the process.
A classic way to overcome this is to combine such a use-after-free bug with an infoleak bug that can leak an address of one of the executable modules. But, there is a problem: In our crop of bugs, there wasn’t a good infoleak we could use for this purpose. A less masochistic vulnerability researcher would simply continue to run the fuzzer until a good infoleak bug would pop up. However, instead of finding better bugs, I deliberately wanted to limit myself to just the bugs found in the same number of iterations as in the previous research. As a consequence, the majority of time spent working on this exploit was to turn the bug into an infoleak.
As stated before, the primitive we have is a virtual method call on the freed object. Without an ASLR bypass, the only thing we can do with it that would not cause an immediate crash is to replace the freed object with another object that also has a vtable, so that when a virtual method is called, it is called on the other object. Most of the time, this would mean calling a valid virtual method on a valid object and nothing interesting would happen. However, there are several scenarios where doing this could lead to interesting results:
  1. The virtual method could be something dangerous to call out-of-context. For example, if we can call a destructor of some object, its members could get freed while the object itself continues to live. With this, we could turn the original use-after-free issue into another use-after-free issue, but possibly one that gives us a better exploitation primitive.

  1. Since constructFromString() takes a single parameter of the type String, we could potentially cause a type confusion on the input parameter if the other virtual method expects a parameter of another type. Additionally, if the other virtual method takes more parameters than constructFromString(), these would be uninitialized which could also lead to exploitable behavior.

  1. As constructFromString() is expected to return a pointer of type SVGAnimatedType, if the other virtual method returns some other type, this will lead to the type confusion on the return value. Additionally, if the other virtual method does not return anything, then the return value remains uninitialized.

  1. If the vtables of the freed object and the object we replaced it with are of different size, calling a vtable pointer on the freed object could result in an out-of-bounds read on the vtable of the other object, resulting in calling a virtual function of some third class.

In this exploit we used option 3, but with a twist. To understand what the twist is, let’s examine the SVGAnimateElementBase class more closely: It implements (most of) the functionality of the SVG <animate> element. The SVG <animate> element is used to, as the name suggests, animate a property of another element. For example, having the following element in an SVG image
<animate attributeName="x" from="0" to="100" dur="10s" />
will cause the x coordinate of the target element (by default, the parent element) to grow from 0 to 100 over the duration of 10 seconds. We can use an <animate> element to animate various CSS or XML properties, which is controlled by the attributeName property of the <animate> element.
Here’s the interesting part: These properties can have different types. For example, we might use an <animate> element to animate the x coordinate of an element, which is of type SVGLengthValue (number + unit), or we might use it to animate the fill attribute, which is of type Color.
In an SVGAnimateElementBase class, the type of animated property is tracked via a member variable declared as
   AnimatedPropertyType m_animatedPropertyType;
Where AnimatedPropertyType is the enumeration of possible types. Two other member variables of note are
   std::unique_ptr<SVGAnimatedTypeAnimator> m_animator;    std::unique_ptr<SVGAnimatedType> m_animatedType;
The m_animator here is the use-after-free object, while m_animatedType is the object created from the (possibly freed) m_animator.
SVGAnimatedTypeAnimator (type of m_animator) is a superclass which has subclasses for all possible values of AnimatedPropertyType, such as SVGAnimatedBooleanAnimator, SVGAnimatedColorAnimator etc. SVGAnimatedType (type of m_animatedType) is a variant that contains a type and a union of possible values depending on the type.
The important thing to note is that normally, both the subclass of m_animator and the type of m_animatedType are supposed to match m_animatedPropertyType. For example, if m_animatedPropertyType is AnimatedBoolean, then the type of m_animatedType variant should be the same, and m_animator should be an instance of SVGAnimatedBooleanAnimator.
After all, why shouldn’t all these types match, since m_animator is created based on m_animatedPropertyType here and m_animatedType is created by m_animator here. Oh wait, that’s exactly where the vulnerability occurs!
So instead of replacing a freed animator with something completely different and causing a type confusion between SVGAnimatedType and another class, we can instead replace the freed animator with another animator subclass and confuse SVGAnimatedType with type = A to another SVGAnimatedType with type = B.
But one interesting thing about this bug is that it would still be a bug even if the animator object did not get freed. In that case, the bug turns into a type confusion: To trigger it, one would simply change the m_animatedPropertyType of the <animate> element to a different type in the JavaScript callback (we’ll examine how this happens in detail later). This led to some discussion in the office whether the bug should be called an use-after-free at all, or is this really a different type of bug where the use-after-free is merely a symptom.
Note that the animator object is always going to get freed as soon as the type of the <animate> element changes, which leads to an interesting scenario where to exploit a bug (however you choose to call it), instead of replacing the freed object with an object of another type, we could either replace it with the object of the same type or make sure it doesn’t get replaced at all. Due to how memory allocation in WebKit works, the latter is actually going to happen on its own most of the time anyway - objects allocated in a memory page will only start getting replaced once the whole page becomes full. Additionally, freeing an object in WebKit doesn’t corrupt it as would be the case in some other allocators, which allows us to still use it normally even after being freed.
Let’s now examine how this type confusion works and what effects it has:
  1. We start with an <animate> element for type A. m_animatedPropertyType, m_animator and m_animatedType all match type A.

  1. resetAnimatedType() gets called and it retrieves an animator pointer of type A here.

  1. resetAnimatedType() calls computeCSSPropertyValue() here, which triggers a JavaScript callback.

  1. In the JavaScript callback, we change the type of <animate> element to B by changing its attributeName attribute. This causes SVGAnimateElementBase::resetAnimatedPropertyType() to be called. In it, m_animatedType and m_animator get deleted, while m_animatedPropertyType gets set to B according to the new attributeName here. Now, m_animatedType and m_animator are null, while m_animatedPropertyType is B.

  1. We return into resetAnimatedType(), where we still have a local variable animator which still points to (freed but still functional) animator for type A.

  1. m_animatedType gets created based on the freed animator here. Now, m_animatedType is of type A, m_animatedPropertyType is B and m_animator is null.

  1. resetAnimatedType() returns, and the animator local variable pointing to the freed animator of type A gets lost, never to be seen again.

  1. Eventually, resetAnimatedType() gets called again. Since m_animator is still null, but m_animatedPropertyType is B, it creates m_animator of type B here.

  1. Since m_animatedType is non-null, instead of creating it anew, we just initialize it by calling m_animatedType->setValueAsString() here. We now have m_animatedPropertyType for type B, m_animator for type B and m_animatedType for type A.

  1. At some point, the value of the animated property gets calculated. That happens in SVGAnimateElementBase::calculateAnimatedValue() on this line by calling m_animator->calculateAnimatedValue(..., m_animatedType). Here, there is a mismatch between the m_animator (type B) and  m_animatedType (type A). However, because the mismatch wouldn’t normally occur, the animator won’t check the type of the argument (there might be some debug asserts but nothing in the release) and will attempt to write the calculated animated value of type B into the SVGAnimatedType with type A.

  1. After the animated value has been computed, it is read out as string and set to the corresponding CSS property. This happens here.

The actual type confusion only happens in step 10: there, we will write to the SVGAnimatedType of type A as if it actually was type B. The rest of the interactions with m_animatedType are not dangerous since they are simply getting and setting the value as string, an operation that is safe to do regardless of the actual type.
Note that, although the <animate> element supports animating XML properties as well as CSS properties, we can only do the above dance with CSS properties as the code for handling XML properties is different. The list of CSS properties we can work with can be found here.
So, how do we exploit this type confusion for an infoleak? The initial idea was to exploit with A = <some numeric type> and B = String. This way, when the type confusion on write occurs, a string pointer is written over a number and then we would be able to read it in step 11 above. But there is a problem with this (as well as with a large number of type combinations): The value read in step 11 must be a valid CSS property value in the context of the current animated property, otherwise it won’t be set correctly and we would not be able to read it out. For example, we were unable to find a string CSS property (from the list above) that would accept a value like 1.4e-45 or similar.
A more promising approach, due to limitations of step 11, would be to replace a numeric type with another numeric type. We had some success with A = FloatRect and B = SVGLengthListValues, which is a vector of SVGLengthValue values. Like above, this results in a vector pointer being written over FloatRect type. This sometimes leads to successfully disclosing a heap address. Why sometimes? Because the only CSS property with type SVGLengthListValues we can use is stroke-dasharray, and stroke-dasharray accepts only positive values. Thus, if lower 32-bits of the heap address we want to disclose look like a negative floating point number (i.e. the highest bit is set), then we would not be able to disclose that address. This problem can be overcome by spraying the heap with 2GB of data so that the lower 32-bits of heap addresses start becoming positive. But, since we need heap spraying anyway, there is another approach we can take.
The approach we actually ended up using is with A = SVGLengthListValues (stroke-dasharray CSS property) and B = float (stroke-miterlimit CSS property). What this type confusion does, is overwrites the lowest 32 bits of a SVGLengthValue vector with a floating point number.
Before we trigger this type confusion we need to spray the heap with approximately 4GB of data (doable on modern computers), which gives us a good probability that when we change an original heap address 0x000000XXXXXXXXXX to 0x000000XXYYYYYYYY, the resulting address is still going to be a valid heap address, especially if YYYYYYYY is high. This way, we can disclose not-quite-arbitrary data at 0x000000XX00000000 + arbitrary offset.
Why not-quite-arbitrary? Because there are still some limitations:
  1. As stroke-miterlimit must be positive, once again we can only disclose data from the heap interpretable as a 32-bit float.

  1. SVGLengthValue is a type which consists of a 32-bit float followed by an enumeration that describes the units used. When a SVGLengthValue is read out as string in step 11 above, if the unit value is valid, it will be appended to the number (e.g. ‘100px’). If we attempt to set a string like that to the stroke-miterlimit property it will fail. Thus, the next byte after the heap value we want to read must interpret as invalid unit (in which case the unit is not appended when reading out SVGLengthValue as string).

Note that both of these limitations can often be worked around by doing non-aligned reads.
Now that we have our more-or-less usable read, what do we read out? As the whole point is to defeat ASLR, we should read a pointer to an executable module. Often in exploitation, one would do that by reading out the vtable pointer of some object on the heap. However, on MacOS it appears that vtable pointers point to a separate memory region than the one containing executable code of the corresponding module. So instead of reading out a vtable pointer, we need to read a function pointer instead.
What we ended up doing is using VTTRegion objects in our heap spray. A VTTRegion object contains a Timer which contains a pointer to Function object which (in this case) contains a function pointer to VTTRegion::scrollTimerFired(). Thus, we can spray with VTTRegion objects (which takes about 10 seconds on a quite not-state-of-the-art Mac Mini) and then scan the resulting memory for a function pointer.
This gives us the ASLR bypass, but one other thing useful to have for the next phase is the address of the payload (ROP chain and shellcode). We disclose it by the following steps:
  1. Find a VTTRegion object in the heap spray.

  1. By setting the VTTRegion.height property during the heap spray to an index in the spray array, we can identify exactly which of the millions of VTTRegion objects we just read.

  1. Set the VTTRegion.id property of the VTTRegion object to the payload.

  1. Read out the VTTRegion.id pointer.

We are now ready for triggering the vulnerability a second time, this time for code exec. This time, it is the classic use-after-free exploitation scenario: we overwrite the freed SVGAnimatedTypeAnimator object with the data we control.
As Apple recently introduced gigacage (a separate large region of memory) for a lot of attacker-controlled datatypes (strings, arrays, etc.) this is no longer trivial. However, one thing still allocated on the main heap is Vector content. By finding a vector whose content we fully control, we can overcome the heap limitations.
What I ended up using is a temporary vector used when TypedArray.set() is called to copy values from one JavaScript typed array into another typed array. This vector is temporary, meaning it will be deleted immediately after use, but again, due to how memory allocation works in webkit it is not too horrible. Like other stability improvements, the task of finding a more permanent controllable allocation is left to the exercise of the reader. :-)
This time, in the JavaScript event handler, we can replace the freed SVGAnimatedTypeAnimator with a vector whose first 8 bytes are set to point to the ROP chain + shellcode payload.
The ROP chain is pretty straightforward, but one thing that is perhaps more interesting is the stack pivot gadget (or, in this case, gadgets) used. In the scenario we have, the virtual function on the freed object is called as
call qword ptr [rax+10h]
where rax points to our payload. Additionally, rsi points to the freed object (that we now also control). The first thing we want to do for ROP is control the stack, but I was unable to find any “classic” gadgets that accomplish this such as
mov rsp, rax; ret;push rax; pop rsp; ret;xchg rax, rsp; ret;
What I ended up doing is breaking the stack pivot into two gadgets:
push rax; mov rax, [rsi], call [rax + offset];
This first gadget pushes the payload address on the stack and is very common because, after all, that’s exactly how the original virtual function was called (apart from push rax that can be an epilogue of some other instruction). The second gadget can then be
pop whatever; pop rsp; ret;
where the first pop pops the return address from the stack and the second pop finally gets the controlled value into rsp. This gadget is less common, but still appears to be way more common than the stack pivot mentioned previously, at least in our binary.
The final ROP chain is (remember to start reading from offset 0x10):
[address of pop; pop; pop; ret]0[address of push rax; mov rax, [rsi], call [rax+0x28]];0[address of pop; ret][address of pop rbp; pop rsp; ret;][address of pop rdi; ret]0[address of pop rsi; ret]shellcode length[address of pop rdx; ret]PROT_EXEC + PROT_READ + PROT_WRITE[address of pop rcx; ret]MAP_ANON + MAP_PRIVATE[address of pop r8; pop rbp; ret]-10[address of pop r9; ret]0[address of mmap][address of push rax; pop rdi; ret][address of push rsp; pop rbp; ret][address of push rbp; pop rax; ret][address of add rax, 0x50; pop rbp; ret]0[address of push rax; pop rsi; pop rbp; ret]0[address of pop rdx; ret]shellcode length[address of memcpy][address of jmp rax;]0shellcode
The ROP chain calls
mmap(0, shellcode_length,  PROT_EXEC | PROT_READ | PROT_WRITE, MAP_ANON + MAP_PRIVATE, -1, 0)
Then calculates the shellcode address and copies it to the address returned by mmap(), after which the shellcode is called.
In our case, the shellcode is just a sequence of ‘int 3’ instructions and when reaching it, Safari will crash. If a debugger is attached, we can see that the shellcode was successfully reached as it will detect a breakpoint:
Process 5833 stopped* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)    frame #0: 0x00000001b1b83001->  0x1b1b83001: int3       0x1b1b83002: int3       0x1b1b83003: int3       0x1b1b83004: int3   Target 0: (com.apple.WebKit.WebContent) stopped.
In the real-world scenario the shellcode could either be a second-stage exploit to break out of the Safari sandbox or, alternately, a payload that would turn the issue into an universal XSS, stealing cross-domain data.
The exploit was successfully tested on Mac OS 10.13.6 (build version 17G65). If you are still using this version, you might want to update. The full exploit can be seen here.
The impact of recent iOS mitigations
An interesting aspect of this exploit is that, on Safari for Mac OS it could be written in a very “old-school” way (infoleak + ROP) due to lack of control flow mitigations on the platform.
On the latest mobile hardware and in iOS 12, which was published after the exploit was already written, Apple introduced control flow mitigations by using Pointer Authentication Codes (PAC). While there are no plans to write another version of the exploit at this time, it is interesting to discuss how the exploit could be modified not to be affected by the recent mitigations.
The exploit, as presented here, consists of two parts: infoleak and getting code execution. PAC would not affect the infoleak part in any way, however it would prevent jumping to the ROP chain in the second part of the exploit, because we could not forge a correct signature for the vtable pointer.
Instead of jumping to the ROP code, the next stage of the exploit would likely need to be getting an arbitrary read-write primitive. This could potentially be accomplished by exploiting a similar type confusion that was used for the infoleak, but with a different object combination. I did notice that there are some type combinations that could result in a write (especially if the attacker already has an infoleak), but I didn’t investigate those in detail.
In the Webkit process, after the attacker has an arbitrary read-write primitive, they could find a way to overwrite JIT code (or, failing that, other data that would cause fully or partially controlled JIT code to be emitted) and achieve code execution that way.
So while the exploit could still be written, admittedly it would be somewhat more difficult to write.
On publishing the advisories
Before concluding this blog post, we want to draw some attention to how the patches for the issues listed in the blog post were announced and to the corresponding timeline. The issues were reported to Apple between June 15 and July 2nd, 2018. On September 17th 2018, Apple published security advisories for iOS 12, tvOS 12 and Safari 12 which fixed all of the issues. However, although the bugs were fixed at that time, the corresponding advisories did not initially mention them. The issues described in the blog post were only added to the advisories one week later, on September 24, 2018, when the security advisories for macOS Mojave 10.14 were also published.
To demonstrate the discrepancy between originally published advisories and the updated advisories, compare the archived version of Safari 12 advisories from September 18 here and the current version of the same advisories here (note that you might need to refresh the page if you still have the old version in your browser’s cache).
The original advisories most likely didn’t include all the issues because Apple wanted to wait for the issues to also be fixed on MacOS before adding them. However, this practice is misleading because customers interested in the Apple security advisories would most likely read them only once, when they are first released and the impression they would to get is that the product updates fix far less vulnerabilities and less severe vulnerabilities than is actually the case.
Furthermore, the practice of not publishing fixes for mobile or desktop operating systems at the same time can put the desktop customers at unnecessary risk, because attackers could reverse-engineer the patches from the mobile updates and develop exploits against desktop products, while the desktop customers would have no way to update and protect themselves.
Conclusion
While there were clearly improvements in WebKit DOM when tested with Domato, the now public fuzzer was still able to find a large number of interesting bugs in a non-overly-prohibitive number of iterations. And if a public tool was able to find that many bugs, it is expected that private ones might be even more successful.
And while it is easy to brush away such bugs as something we haven’t seen actual attackers use, that doesn’t mean it’s not happening or that it couldn’t happen, as the provided exploit demonstrates. The exploit doesn’t include a sandbox escape so it can’t be considered a full chain, however reports from other security researchers indicate that this other aspect of browser security, too, cracks under fuzzing (Note from Apple Security: this sandbox escape relies on attacking the WindowServer, access to which has been removed from the sandbox in Safari 12 on macOS Mojave 10.14). Additionally, a DOM exploit could be used to steal cross-domain data such as cookies even without a sandbox escape.
The fuzzing results might indicate that WebKit is getting fuzzed, but perhaps not with sufficient computing power to find all fuzzable, newly introduced bugs before they make it into the release version of the browser. We are hoping that this research will lead to improved user security by providing an incentive for Apple to allocate more resources into this area of browser security.
Categories: Security

IBM Z Connectivity Handbook

IBM Redbooks Site - Tue, 10/02/2018 - 09:30
Redbook, published: Tue, 2 Oct 2018

This IBM® Redbooks® publication describes the connectivity options that are available for use within and beyond the data center for the IBM Z family of mainframes, which includes these systems:

  • IBM z14®
  • IBM z14 Model ZR1
  • IBM z13®
  • IBM z13s™
  • IBM zEnterprise® EC12 (zEC12)
  • IBM zEnterprise BC12 (zBC12)
This book highlights the hardware and software components, functions, typical uses, coexistence, and relative merits of these connectivity features.
Categories: Technology

IBM Z Functional Matrix

IBM Redbooks Site - Tue, 10/02/2018 - 09:30
Redpaper, published: Tue, 2 Oct 2018

This IBM® Redpaper™ publication provides a list of features and functions that are supported on IBM Z, including the IBM z14(z14) - Machine types 3906 and 3907, IBM z13TM(z13®), IBM z13s™(z13s), IBM zEnterprise® EC12 (zEC12), and IBM zEnterprise BC12 (zBC12).

Categories: Technology

IBM z14 Model ZR1 Technical Introduction

IBM Redbooks Site - Tue, 10/02/2018 - 09:30
Redbook, published: Tue, 2 Oct 2018

This IBM® Redbooks® publication introduces the latest member of the IBM Z platform, the IBM z14 Model ZR1 (Machine Type 3907).

Categories: Technology

IBM z14 Technical Introduction

IBM Redbooks Site - Tue, 10/02/2018 - 09:30
Redbook, published: Tue, 2 Oct 2018

This IBM® Redbooks® publication introduces the latest IBM z platform, the IBM z14™.

Categories: Technology

Presidential Alert coming tomorrow, October 3.

iPhone J.D. - Tue, 10/02/2018 - 01:41

A few years ago, I wrote about wireless emergency alerts on the iPhone, and I explained that there are three kinds:  (1) emergency alerts issued because of an imminent threat to public safety or life, such as evacuation orders or shelter in place orders due to severe weather, a terrorist threat, or a chemical spill; (2) AMBER alerts for when a child is abducted, and (3) Presidential Alerts.  All three alerts arise out of the Warning Alert and Response Network Act, sometimes called the WARN Act, 47 U.S.C. § 1201, and more specifically the Wireless Emergency Alerts (WEA) program which was created pursuant to the WARN Act by the FCC working with FEMA.

When I wrote that post in 2013, I noted that no president had ever issued a Presidential Alert under WEA or similar prior systems.  And I also noted that while the WARN Act provides in 47 U.S.C. § 1201(b)(2)(E) that cell phone users may opt-out of emergency alerts and AMBER Alerts, a user may not opt-out of Presidential Alerts.  Thus, if you open the Settings app on your iPhone and tap Notifications and then scroll to the bottom, you will see that you only have on/off switches for the first two types of alerts:

Tomorrow, October 3, 2018 at 2:18 p.m. Eastern / 1:18 p.m. Central / 12:18 p.m. Mountain / 11:18 a.m. Pacific, FEMA and the FCC will conduct the first-ever test of a Presidential Alert.  Note that while the test will start at 2:18 p.m. Eastern, it will continue for 30 minutes, so if your iPhone doesn't get the alert right away, it may come at some other time during that 30 minute window.  (This test was originally planned for September 20, but it was delayed because of Hurricane Florence.)  The message will have a header that reads "Presidential Alert" and the body of the message will say:  "THIS IS A TEST of the National Wireless Emergency Alert System.  No action is needed."

If you will be in court or somewhere else where it would be inappropriate for your iPhone to make a loud noise, TURN OFF YOUR IPHONE BEFORE THAT TIME.  And if you are around other cellphones that make a loud noise tomorrow, now you know what is going on.

Hopefully the test will be deemed a success and we won't have to go through this again for a long time.  And also, my understanding is that the rumors are false, and President Trump will not begin using the Presidential Alert system to send all of his tweets to each of us.  At least, I hope those rumors are false.

Categories: iPhone Web Sites

Review: Apple Watch Series 4 -- see more, do more

iPhone J.D. - Mon, 10/01/2018 - 00:47

When I reviewed the new 2018 versions of the iPhone, I noted that this is just an "s" year.  There are definitely some nice new features in all of the new iPhones, especially for taking pictures, and if you want a larger screen or a cheaper iPhone X, it is great that Apple has three new models.  Nevertheless, this is not as big of an iPhone upgrade as we saw a year ago.

The opposite is true with the Apple Watch.  The Apple Watch Series 4 is the first significant upgrade to the Apple Watch hardware since the Apple Watch was first previewed in 2014 and started selling in early 2015.  Unlike 2014, when Apple wasn't really sure how the Apple Watch would be used, Apple now has years of experience and knows what people like most about an Apple Watch.  And those are precisely the parts of the Apple Watch that Apple improved.  I've been using the Apple Watch Series 4 for a week, and I am blown away at how amazing this device is.  I use it daily in my law practice, outside of the office for messages and entertainment purposes, when exercising, and pretty much all day long no matter what I'm doing from when I wake up until I go to sleep.  This is an incredibly useful device that I recommend highly to any attorney who uses an iPhone.

The iPhone X version of the Apple Watch

Last year, the iPhone X was a huge leap forward in the iPhone world because Apple figured out a way to make the screen go virtually edge-to-edge.  Thus, the physical size of the iPhone remained familiar, but the usable screen was larger.  You saw much more in the same amount of space.  Apple has applied the same design magic to the Series 4 Apple Watch. There are some changes to the physical size of the watch.  First, the new watch is slightly thinner.  It's not a big change, but it is welcome nevertheless.  In these pictures, my Series 2 is on the left and my Series 4 is on the right:

Another physical change is that the face is slightly larger, with 40 mm and 44 mm sizes instead of the former 42 mm and 38 mm sizes.  This increase is so minor that you probably won't ever notice it unless you put the new Apple Watch next to an old one.  In this picture, my old Apple Watch Series 2 is on the left, and the new Apple Watch Series 4 is on the right:

I've heard some people wonder if the increase from 42 to 44 mm means that a person who previously used a 42 mm should instead get the smaller 40 mm model.  Maybe for some folks this makes sense, but I suspect that most folks who have previously used a 42 mm will be perfectly happy with the 44 mm.  It's really not a big difference in physical size.

The real change to the size of the Apple Watch is that, much like the iPhone X, Apple has brought the usable screen closer to the edges of the watch.  As a result of the improvements, the new screen is now 30% larger.

This is a huge, noticeable improvement.  The additional information that you can see is fantastic.  For example, I've always been able to look at an email on my Apple Watch, but the size of the watch face severely limits how many words you can see at one time.  With the larger screen on the Series 4, I typically see one additional sentence on the screen as compared to the older models.  For longer emails, I'll have to use the scroll wheel to scroll down on either watch, but less scrolling is necessary on the Series 4.  The same is true for text messages and any other app which puts lots of information on the screen.  You see more, and thus you can obtain, and can act upon, the information more quickly.

Other apps simply expand to fill the larger screen so you get a larger watch face, larger controls for music and podcasts, etc.  For these tasks, the larger face makes the Apple Watch much easier and more enjoyable to use.  Here's a s simple example, but one which matters because I do it every day:  typing in my passcode to unlock my Apple Watch is far easier with the larger screen on the Series 4 with the larger buttons.

The larger screen also makes it possible to have new watch faces with many more complications.  The following picture uses the new Infograph watch face that Apple keeps showing off in its press pictures.  It has eight complications in addition to the time:

I am not sure if I am going to use the Infograph as it seems a little too busy to me, plus I prefer digital time over hands on a watch face, but I love that this is an option.

Note that even with the different screen and sizes, you can still use your old Apple Watch bands with the new Series 4.  That's good news for me because I love my Milanese Loop watch band, but it is $150 so I'm glad that I didn't have to buy a new one.

Faster

Early models of the Apple Watch were rather slow, which had a negative impact on usability.  But with each new generation, the Apple Watch gets faster.  The Series 4 is the first Apple Watch to feature a 64-bit processor, which Apple says is twice as fast as the Series 3 — which was 70% faster than the Series 2, and the Series 2 was 50% faster than the original Apple Watch.  Thus, if you are upgrading from an earlier version of the Apple Watch, this speed increase should be quite noticeable — especially if you are using something older than a Series 3.

At this point, you may be thinking "ho hum, it's faster, but every new model is faster."  Fair enough, but this time, the speed increase has real consequences.  With the Series 4, the Apple Watch has crossed over from being a device that operates so slowly that sometimes I just don't bother to use it into a device which operates so quickly that I have no hesitation to use the device to perform tasks.

Let's go back to that email example.  On my Series 2, working with emails works fine, but it is somewhat slow.  On the Series 4, working with email is lightning fast, just as fast as working with emails on my iPhone.  Because of this speed increase, along with the larger screen, I am working with emails on my Apple Watch far more than I ever have before.  I can very quickly triage my inbox by deleting the junk mail and mail that doesn't really interest me.  I can quickly read emails that do matter to me and then act upon them.  Responding to emails is still easier on an iPhone or iPad if I need to type something of substance, but if I just want to send a quick reply, the watch works fine.  And of course I can dictate or scribble out the words of a longer reply if I need to do so.

If your law practice is anything like mine, this is huge.  I get tons of email every day.  When new emails come in, with the Series 4 I can often deal with them faster on my Apple Watch than on my iPhone, in large part because the watch is right their on my wrist whereas I need to dig out the iPhone and then put it away when I'm finished.  Plus, when I pick up my iPhone, there is a greater risk that I will be distracted by some other app on the iPhone.  When working with emails on my Apple Watch, I get in and out more quickly and then get back to my work.  I had no idea before using the Series 4 a week ago that working with emails would be so dramatically improved thanks to the larger screen and the faster watch.

Here's another example where the speed has a direct effect on usability.  I have lots of lights in my house which are controlled by HomeKit,  It is handy to use my Apple Watch to turn lights on and off, sometimes by speaking to Siri, other times by tapping a button in the Home app on the watch.  On my Series 2, sometimes this feature worked OK, and other times it was so slow that it was painful.  With my Series 4 watch, HomeKit devices respond to my Apple Watch commands right away — as quickly as commands coming from an iPhone.  The speed increase means that I no longer hesitate to use my Apple Watch with HomeKit devices, and thus it is almost like HomeKit performance is an additional feature of the Series 4.

Cellular

Apple added cellular support to the Apple Watch Series 3, but I never owned a Series 3 so I've been using cellular on my Apple Watch for the first time this week.  Thanks to a new ceramic back, which reduces interference with radio waves, Apple says that cellular activity is works even better on the Series 4.

Before last week, I didn't think that this would be that significant for me.  After all, don't I carry my iPhone pretty much all the time?  But it has been been a nicer feature than I expected, especially when I've walked or jogged in a park to try to close my activity circles.  There often isn't really a good place to put an iPhone in exercise clothes, and with the Series 4, I don't have to.  I pair my AirPods with my Apple Watch, and then I'm off.  I've tested receiving and sending emails, receiving and sending text messages, and placing and picking up phone calls when my Apple Watch is using cellular.  It all just works.  It is so nice to know that I'm connected to the outside world in case someone needs me or I need to contact someone else – even though I'm not carrying around a heavy iPhone.  Indeed, I don't even feel the weight of an Apple Watch on my arm or AirPods in my ears, so I get all of this without feeling ANY extra weight at all.

Digital Crown

As part of the redesign, Apple made the Digital Crown on the side smaller.  I don't notice the difference in normal usage.  Apple also added haptic feedback when spinning the Digital Crown, and the clicks make a big difference.  It makes spinning the crown feel far more precise because you feel a click as each item is passed on the scrolling list.  If you haven't tried a Series 4 yet this might not sound like a very big deal, but in normal usage it is really nice. 

EKG

In addition to monitoring your heart beats, the Series 4 adds the ability to check your heart activity by running a simple EKG test (sometimes called an ECG).  Just put your finger on the digital crown, start the test, and you'll get results in 30 seconds.  I'm a lawyer not a doctor, but from what I've been reading for the last few days, this feature can help to save lives.

For example, here is a post on Reddit by a doctor explaining that the new Apple Watch can help to detect Atrial Fibrillation, which is the most common cardiac arrhythmia, and something that is experienced by up to 25% of people over 40 years old.

Note that this EKG feature requires a special app, which Apple says it will release later this year.  And for many folks, this feature will be unimportant.  But for some folks, especially those working with a heart doctor, this feature could be literally life changing.

Louder

The new speaker in the Apple Watch is 50% louder.  And the microphone was moved to the right side of the Apple Watch (the opposite side as the speaker) to reduce interference.  If you are using your Apple Watch to make phone calls or to use the new Walkie-Talkie feature, the improved speaker should help.  I usually keep sounds turned off on my Apple Watch, so this feature doesn't matter so much to me.

Fall detection

The Series 4 Apple Watch includes a more advanced accelerometer and gyroscope which can detect if you fall.  And if you fall down and then don't move for 60 seconds, the Apple Watch can even call 911 and your emergency contacts.  For folks above a certain age — or for anyone who can be clumsy — this looks like a feature that you hope to never use, but that you will very much appreciate if you need it.

Etc.

There is a lot more that is packed into the Apple Watch Series 4, including new watch faces, Bluetooth 5.0 (which I hope will improve communications between the Apple Watch and the iPhone), increased battery life for outdoor workouts when you are using GPS, and more.

Models

This is the first version of the Apple Watch that does not come in a more expensive Special Edition version made of high-end materials (gold in the first Apple Watch, ceramic in later models).  However, there is now a new gold stainless steel version of the watch.  You can also select the Nike+ version or the Hermès versions, which include different watch bands and a special watch face.

Apple no longer calls the aluminum version of the Apple Watch the "sport" model.  You just get an Apple Watch, and you choose whether you want aluminum and stainless steel, with stainless steel costing $300 more.  I prefer the look and feel of the stainless steel over aluminum, and I also like that the stainless steel version has a more durable screen — a sapphire crystal face, instead of Ion-X glass.  Even though I have hit the face of my Series 2 Apple Watch on countless objects over the yaars, I have never gotten a scratch.  My wife is far more poised and less clumsy than me, but her Series 2 aluminum Apple Watch does have some small scratches.

Conclusion

I was really excited about the iPhone X when it came out a year ago, and I absolutely loved using it for the past year.  I feel the same way about the Apple Watch Series 4.  The larger screen and the increase in speed make everything better.  Indeed, some features are so much better than I am using them far more than ever before.  The Apple Watch Series 4 is a huge leap forward.  If you have been thinking about getting an Apple Watch but were waiting for the right time, that time is now.  If you have an older Apple Watch and you already know that it is a useful device for you, upgrading to a Series 4 will be a huge improvement to what you already love.

Categories: iPhone Web Sites

Introducing the IBM DS8882F Rack Mounted Storage system

IBM Redbooks Site - Fri, 09/28/2018 - 09:30
Draft Redpaper, last updated: Fri, 28 Sep 2018

This IBM® Redpaper™ presents and positions the DS8882F.

Categories: Technology

DS8880 SafeGuarded Copy

IBM Redbooks Site - Fri, 09/28/2018 - 09:30
Draft Redpaper, last updated: Fri, 28 Sep 2018

This IBM RedPaper publication explains the DS8880 Safeguarded Copy functionality.

Categories: Technology

In the news

iPhone J.D. - Fri, 09/28/2018 - 00:27

This is the best time of the year for the iPhone.  We have new devices, and the iPhone XS has been a real champ for me this week during a crazy busy week for me both at work and after work.  We are also seeing more apps being updated to work with iOS 12 and watchOS 5.  And CarPlay has been seeing some nice improvements thanks to more third party apps.  Here is the news of note from the past week:

Categories: iPhone Web Sites

Introduction and Implementation of Data Reduction Pools and Deduplication

IBM Redbooks Site - Thu, 09/27/2018 - 09:30
Draft Redbook, last updated: Thu, 27 Sep 2018

Continuing its commitment to developing and delivering industry-leading storage technologies, IBM® introduces Data Reduction Pools (DRP) and Deduplication powered by IBM Spectrum™ Virtualize, which are innovative storage features that deliver essential storage efficiency technologies and exceptional ease of use and performance, all integrated into a proven design.

Categories: Technology

A cache invalidation bug in Linux memory management

Google Project Zero - Wed, 09/26/2018 - 13:16
Posted by Jann Horn, Google Project Zero
This blogpost describes a way to exploit a Linux kernel bug (CVE-2018-17182) that exists since kernel version 3.16. While the bug itself is in code that is reachable even from relatively strongly sandboxed contexts, this blogpost only describes a way to exploit it in environments that use Linux kernels that haven't been configured for increased security (specifically, Ubuntu 18.04 with kernel linux-image-4.15.0-34-generic at version 4.15.0-34.37). This demonstrates how the kernel configuration can have a big impact on the difficulty of exploiting a kernel bug.
The bug report and the exploit are filed in our issue tracker as issue 1664.
Fixes for the issue are in the upstream stable releases 4.18.9, 4.14.71, 4.9.128, 4.4.157 and 3.16.58.The bugWhenever a userspace page fault occurs because e.g. a page has to be paged in on demand, the Linux kernel has to look up the VMA (virtual memory area; struct vm_area_struct) that contains the fault address to figure out how the fault should be handled. The slowpath for looking up a VMA (in find_vma()) has to walk a red-black tree of VMAs. To avoid this performance hit, Linux also has a fastpath that can bypass the tree walk if the VMA was recently used.
The implementation of the fastpath has changed over time; since version 3.15, Linux uses per-thread VMA caches with four slots, implemented in mm/vmacache.c and include/linux/vmacache.h. Whenever a successful lookup has been performed through the slowpath, vmacache_update() stores a pointer to the VMA in an entry of the array current->vmacache.vmas, allowing the next lookup to use the fastpath.
Note that VMA caches are per-thread, but VMAs are associated with a whole process (more precisely with a struct mm_struct; from now on, this distinction will largely be ignored, since it isn't relevant to this bug). Therefore, when a VMA is freed, the VMA caches of all threads must be invalidated - otherwise, the next VMA lookup would follow a dangling pointer. However, since a process can have many threads, simply iterating through the VMA caches of all threads would be a performance problem.
To solve this, both the struct mm_struct and the per-thread struct vmacache are tagged with sequence numbers; when the VMA lookup fastpath discovers in vmacache_valid() that current->vmacache.seqnum and current->mm->vmacache_seqnum don't match, it wipes the contents of the current thread's VMA cache and updates its sequence number.
The sequence numbers of the mm_struct and the VMA cache were only 32 bits wide, meaning that it was possible for them to overflow. To ensure that a VMA cache can't incorrectly appear to be valid when current->mm->vmacache_seqnum has actually been incremented 232 times, vmacache_invalidate() (the helper that increments current->mm->vmacache_seqnum) had a special case: When current->mm->vmacache_seqnum wrapped to zero, it would call vmacache_flush_all() to wipe the contents of all VMA caches associated with current->mm. Executing vmacache_flush_all() was very expensive: It would iterate over every thread on the entire machine, check which struct mm_struct it is associated with, then if necessary flush the thread's VMA cache.
In version 3.16, an optimization was added: If the struct mm_struct was only associated with a single thread, vmacache_flush_all() would do nothing, based on the realization that every VMA cache invalidation is preceded by a VMA lookup; therefore, in a single-threaded process, the VMA cache's sequence number is always close to the mm_struct's sequence number:
/* * Single threaded tasks need not iterate the entire * list of process. We can avoid the flushing as well * since the mm's seqnum was increased and don't have * to worry about other threads' seqnum. Current's * flush will occur upon the next lookup. */ if (atomic_read(&mm->mm_users) == 1) return;
However, this optimization is incorrect because it doesn't take into account what happens if a previously single-threaded process creates a new thread immediately after the mm_struct's sequence number has wrapped around to zero. In this case, the sequence number of the first thread's VMA cache will still be 0xffffffff, and the second thread can drive the mm_struct's sequence number up to 0xffffffff again. At that point, the first thread's VMA cache, which can contain dangling pointers, will be considered valid again, permitting the use of freed VMA pointers in the first thread's VMA cache.
The bug was fixed by changing the sequence numbers to 64 bits, thereby making an overflow infeasible, and removing the overflow handling logic.Reachability and ImpactFundamentally, this bug can be triggered by any process that can run for a sufficiently long time to overflow the reference counter (about an hour if MAP_FIXED is usable) and has the ability to use mmap()/munmap() (to manage memory mappings) and clone() (to create a thread). These syscalls do not require any privileges, and they are often permitted even in seccomp-sandboxed contexts, such as the Chrome renderer sandbox (mmap, munmap, clone), the sandbox of the main gVisor host component, and Docker's seccomp policy.
To make things easy, my exploit uses various other kernel interfaces, and therefore doesn't just work from inside such sandboxes; in particular, it uses /dev/kmsg to read dmesg logs and uses an eBPF array to spam the kernel's page allocator with user-controlled, mutable single-page allocations. However, an attacker willing to invest more time into an exploit would probably be able to avoid using such interfaces.
Interestingly, it looks like Docker in its default config doesn't prevent containers from accessing the host's dmesg logs if the kernel permits dmesg access for normal users - while /dev/kmsg doesn't exist in the container, the seccomp policy whitelists the syslog() syscall for some reason.BUG_ON(), WARN_ON_ONCE(), and dmesgThe function in which the first use-after-free access occurs is vmacache_find(). When this function was first added - before the bug was introduced -, it accessed the VMA cache as follows:
      for (i = 0; i < VMACACHE_SIZE; i++) {               struct vm_area_struct *vma = current->vmacache[i];
              if (vma && vma->vm_start <= addr && vma->vm_end > addr) {                       BUG_ON(vma->vm_mm != mm);                       return vma;               }       }
When this code encountered a cached VMA whose bounds contain the supplied address addr, it checked whether the VMA's ->vm_mm pointer matches the expected mm_struct - which should always be the case, unless a memory safety problem has happened -, and if not, terminated with a BUG_ON() assertion failure. BUG_ON() is intended to handle cases in which a kernel thread detects a severe problem that can't be cleanly handled by bailing out of the current context. In a default upstream kernel configuration, BUG_ON() will normally print a backtrace with register dumps to the dmesg log buffer, then forcibly terminate the current thread. This can sometimes prevent the rest of the system from continuing to work properly - for example, if the crashing code held an important lock, any other thread that attempts to take that lock will then deadlock -, but it is often successful in keeping the rest of the system in a reasonably usable state. Only when the kernel detects that the crash is in a critical context such as an interrupt handler, it brings down the whole system with a kernel panic.
The same handler code is used for dealing with unexpected crashes in kernel code, like page faults and general protection faults at non-whitelisted addresses: By default, if possible, the kernel will attempt to terminate only the offending thread.
The handling of kernel crashes is a tradeoff between availability, reliability and security. A system owner might want a system to keep running as long as possible, even if parts of the system are crashing, if a sudden kernel panic would cause data loss or downtime of an important service. Similarly, a system owner might want to debug a kernel bug on a live system, without an external debugger; if the whole system terminated as soon as the bug is triggered, it might be harder to debug an issue properly.On the other hand, an attacker attempting to exploit a kernel bug might benefit from the ability to retry an attack multiple times without triggering system reboots; and an attacker with the ability to read the crash log produced by the first attempt might even be able to use that information for a more sophisticated second attempt.
The kernel provides two sysctls that can be used to adjust this behavior, depending on the desired tradeoff:
  • kernel.panic_on_oops will automatically cause a kernel panic when a BUG_ON() assertion triggers or the kernel crashes; its initial value can be configured using the build configuration variable CONFIG_PANIC_ON_OOPS. It is off by default in the upstream kernel - and enabling it by default in distributions would probably be a bad idea -, but it is e.g. enabled by Android.
  • kernel.dmesg_restrict controls whether non-root users can access dmesg logs, which, among other things, contain register dumps and stack traces for kernel crashes; its initial value can be configured using the build configuration variable CONFIG_SECURITY_DMESG_RESTRICT. It is off by default in the upstream kernel, but is enabled by some distributions, e.g. Debian. (Android relies on SELinux to block access to dmesg.)

Ubuntu, for example, enables neither of these.

The code snippet from above was amended in the same month as it was committed:
      for (i = 0; i < VMACACHE_SIZE; i++) {                struct vm_area_struct *vma = current->vmacache[i]; -               if (vma && vma->vm_start <= addr && vma->vm_end > addr) {-                       BUG_ON(vma->vm_mm != mm);+               if (!vma)+                       continue;+               if (WARN_ON_ONCE(vma->vm_mm != mm))+                       break;+               if (vma->vm_start <= addr && vma->vm_end > addr)                        return vma;-               }        }
This amended code is what distributions like Ubuntu are currently shipping.
The first change here is that the sanity check for a dangling pointer happens before the address comparison. The second change is somewhat more interesting: BUG_ON() is replaced with WARN_ON_ONCE().
WARN_ON_ONCE() prints debug information to dmesg that is similar to what BUG_ON() would print. The differences to BUG_ON() are that WARN_ON_ONCE() only prints debug information the first time it triggers, and that execution continues: Now when the kernel detects a dangling pointer in the VMA cache lookup fastpath - in other words, when it heuristically detects that a use-after-free has happened -, it just bails out of the fastpath and falls back to the red-black tree walk. The process continues normally.
This fits in with the kernel's policy of attempting to keep the system running as much as possible by default; if an accidental use-after-free bug occurs here for some reason, the kernel can probably heuristically mitigate its effects and keep the process working.
The policy of only printing a warning even when the kernel has discovered a memory corruption is problematic for systems that should kernel panic when the kernel notices security-relevant events like kernel memory corruption. Simply making WARN() trigger kernel panics isn't really an option because WARN() is also used for various events that are not important to the kernel's security. For this reason, a few uses of WARN_ON() in security-relevant places have been replaced with CHECK_DATA_CORRUPTION(), which permits toggling the behavior between BUG() and WARN() at kernel configuration time. However, CHECK_DATA_CORRUPTION() is only used in the linked list manipulation code and in addr_limit_user_check(); the check in the VMA cache, for example, still uses a classic WARN_ON_ONCE().

A third important change was made to this function; however, this change is relatively recent and will first be in the 4.19 kernel, which hasn't been released yet, so it is irrelevant for attacking currently deployed kernels.
      for (i = 0; i < VMACACHE_SIZE; i++) {-               struct vm_area_struct *vma = current->vmacache.vmas[i];+               struct vm_area_struct *vma = current->vmacache.vmas[idx]; -               if (!vma)-                       continue;-               if (WARN_ON_ONCE(vma->vm_mm != mm))-                       break;-               if (vma->vm_start <= addr && vma->vm_end > addr) {-                       count_vm_vmacache_event(VMACACHE_FIND_HITS);-                       return vma;+               if (vma) {+#ifdef CONFIG_DEBUG_VM_VMACACHE+                       if (WARN_ON_ONCE(vma->vm_mm != mm))+                               break;+#endif+                       if (vma->vm_start <= addr && vma->vm_end > addr) {+                               count_vm_vmacache_event(VMACACHE_FIND_HITS);+                               return vma;+                       }                }+               if (++idx == VMACACHE_SIZE)+                       idx = 0;        }
After this change, the sanity check is skipped altogether unless the kernel is built with the debugging option CONFIG_DEBUG_VM_VMACACHE.The exploit: Incrementing the sequence numberThe exploit has to increment the sequence number roughly 233 times. Therefore, the efficiency of the primitive used to increment the sequence number is important for the runtime of the whole exploit.
It is possible to cause two sequence number increments per syscall as follows: Create an anonymous VMA that spans three pages. Then repeatedly use mmap() with MAP_FIXED to replace the middle page with an equivalent VMA. This causes mmap() to first split the VMA into three VMAs, then replace the middle VMA, and then merge the three VMAs together again, causing VMA cache invalidations for the two VMAs that are deleted while merging the VMAs.The exploit: Replacing the VMAEnumerating all potential ways to attack the use-after-free without releasing the slab's backing page (according to /proc/slabinfo, the Ubuntu kernel uses one page per vm_area_struct slab) back to the buddy allocator / page allocator:
  1. Get the vm_area_struct reused in the same process. The process would then be able to use this VMA, but this doesn't result in anything interesting, since the VMA caches of the process would be allowed to contain pointers to the VMA anyway.
  2. Free the vm_area_struct such that it is on the slab allocator's freelist, then attempt to access it. However, at least the SLUB allocator that Ubuntu uses replaces the first 8 bytes of the vm_area_struct (which contain vm_start, the userspace start address) with a kernel address. This makes it impossible for the VMA cache lookup function to return it, since the condition vma->vm_start <= addr && vma->vm_end > addr can't be fulfilled, and therefore nothing interesting happens.
  3. Free the vm_area_struct such that it is on the slab allocator's freelist, then allocate it in another process. This would (with the exception of a very narrow race condition that can't easily be triggered repeatedly) result in hitting the WARN_ON_ONCE(), and therefore the VMA cache lookup function wouldn't return the VMA.
  4. Free the vm_area_struct such that it is on the slab allocator's freelist, then make an allocation from a slab that has been merged with the vm_area_struct slab. This requires the existence of an aliasing slab; in a Ubuntu 18.04 VM, no such slab seems to exist.

Therefore, to exploit this bug, it is necessary to release the backing page back to the page allocator, then reallocate the page in some way that permits placing controlled data in it. There are various kernel interfaces that could be used for this; for example:
pipe pages:
  • advantage: not wiped on allocation
  • advantage: permits writing at an arbitrary in-page offset if splice() is available
  • advantage: page-aligned
  • disadvantage: can't do multiple writes without first freeing the page, then reallocating it

BPF maps:
  • advantage: can repeatedly read and write contents from userspace
  • advantage: page-aligned
  • disadvantage: wiped on allocation

This exploit uses BPF maps.The exploit: Leaking pointers from dmesgThe exploit wants to have the following information:
  • address of the mm_struct
  • address of the use-after-free'd VMA
  • load address of kernel code

At least in the Ubuntu 18.04 kernel, the first two of these are directly visible in the register dump triggered by WARN_ON_ONCE(), and can therefore easily be extracted from dmesg: The mm_struct's address is in RDI, and the VMA's address is in RAX. However, an instruction pointer is not directly visible because RIP and the stack are symbolized, and none of the general-purpose registers contain an instruction pointer.
A kernel backtrace can contain multiple sets of registers: When the stack backtracing logic encounters an interrupt frame, it generates another register dump. Since we can trigger the WARN_ON_ONCE() through a page fault on a userspace address, and page faults on userspace addresses can happen at any userspace memory access in syscall context (via copy_from_user()/copy_to_user()/...), we can pick a call site that has the relevant information in a register from a wide range of choices. It turns out that writing to an eventfd triggers a usercopy while R8 still contains the pointer to the eventfd_fops structure.
When the exploit runs, it replaces the VMA with zeroed memory, then triggers a VMA lookup against the broken VMA cache, intentionally triggering the WARN_ON_ONCE(). This generates a warning that looks as follows - the leaks used by the exploit are highlighted:
[ 3482.271265] WARNING: CPU: 0 PID: 1871 at /build/linux-SlLHxe/linux-4.15.0/mm/vmacache.c:102 vmacache_find+0x9c/0xb0[...][ 3482.271298] RIP: 0010:vmacache_find+0x9c/0xb0[ 3482.271299] RSP: 0018:ffff9e0bc2263c60 EFLAGS: 00010203[ 3482.271300] RAX: ffff8c7caf1d61a0 RBX: 00007fffffffd000 RCX: 0000000000000002[ 3482.271301] RDX: 0000000000000002 RSI: 00007fffffffd000 RDI: ffff8c7c214c7380[ 3482.271301] RBP: ffff9e0bc2263c60 R08: 0000000000000000 R09: 0000000000000000[ 3482.271302] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8c7c214c7380[ 3482.271303] R13: ffff9e0bc2263d58 R14: ffff8c7c214c7380 R15: 0000000000000014[ 3482.271304] FS:  00007f58c7bf6a80(0000) GS:ffff8c7cbfc00000(0000) knlGS:0000000000000000[ 3482.271305] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3482.271305] CR2: 00007fffffffd000 CR3: 00000000a143c004 CR4: 00000000003606f0[ 3482.271308] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 3482.271309] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 3482.271309] Call Trace:[ 3482.271314]  find_vma+0x1b/0x70[ 3482.271318]  __do_page_fault+0x174/0x4d0[ 3482.271320]  do_page_fault+0x2e/0xe0[ 3482.271323]  do_async_page_fault+0x51/0x80[ 3482.271326]  async_page_fault+0x25/0x50[ 3482.271329] RIP: 0010:copy_user_generic_unrolled+0x86/0xc0[ 3482.271330] RSP: 0018:ffff9e0bc2263e08 EFLAGS: 00050202[ 3482.271330] RAX: 00007fffffffd008 RBX: 0000000000000008 RCX: 0000000000000001[ 3482.271331] RDX: 0000000000000000 RSI: 00007fffffffd000 RDI: ffff9e0bc2263e30[ 3482.271332] RBP: ffff9e0bc2263e20 R08: ffffffffa7243680 R09: 0000000000000002[ 3482.271333] R10: ffff8c7bb4497738 R11: 0000000000000000 R12: ffff9e0bc2263e30[ 3482.271333] R13: ffff8c7bb4497700 R14: ffff8c7cb7a72d80 R15: ffff8c7bb4497700[ 3482.271337]  ? _copy_from_user+0x3e/0x60[ 3482.271340]  eventfd_write+0x74/0x270[ 3482.271343]  ? common_file_perm+0x58/0x160[ 3482.271345]  ? wake_up_q+0x80/0x80[ 3482.271347]  __vfs_write+0x1b/0x40[ 3482.271348]  vfs_write+0xb1/0x1a0[ 3482.271349]  SyS_write+0x55/0xc0[ 3482.271353]  do_syscall_64+0x73/0x130[ 3482.271355]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2[ 3482.271356] RIP: 0033:0x55a2e8ed76a6[ 3482.271357] RSP: 002b:00007ffe71367ec8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001[ 3482.271358] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000055a2e8ed76a6[ 3482.271358] RDX: 0000000000000008 RSI: 00007fffffffd000 RDI: 0000000000000003[ 3482.271359] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000[ 3482.271359] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffe71367ec8[ 3482.271360] R13: 00007fffffffd000 R14: 0000000000000009 R15: 0000000000000000[ 3482.271361] Code: 00 48 8b 84 c8 10 08 00 00 48 85 c0 74 11 48 39 78 40 75 17 48 39 30 77 06 48 39 70 08 77 8d 83 c2 01 83 fa 04 75 ce 31 c0 5d c3 <0f> 0b 31 c0 5d c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [ 3482.271381] ---[ end trace bf256b6e27ee4552 ]---
At this point, the exploit can create a fake VMA that contains the correct mm_struct pointer (leaked from RDI). It also populates other fields with references to fake data structures (by creating pointers back into the fake VMA using the leaked VMA pointer from RAX) and with pointers into the kernel's code (using the leaked R8 from the page fault exception frame to bypass KASLR).The exploit: JOP (the boring part)It is probably possible to exploit this bug in some really elegant way by abusing the ability to overlay a fake writable VMA over existing readonly pages, or something like that; however, this exploit just uses classic jump-oriented programming.
To trigger the use-after-free a second time, a writing memory access is performed on an address that has no pagetable entries. At this point, the kernel's page fault handler comes in via page_fault -> do_page_fault -> __do_page_fault -> handle_mm_fault -> __handle_mm_fault -> handle_pte_fault -> do_fault -> do_shared_fault -> __do_fault, at which point it performs an indirect call:
static int __do_fault(struct vm_fault *vmf) { struct vm_area_struct *vma = vmf->vma; int ret;
ret = vma->vm_ops->fault(vmf);
vma is the VMA structure we control, so at this point, we can gain instruction pointer control. R13 contains a pointer to vma. The JOP chain that is used from there on follows; it is quite crude (for example, it crashes after having done its job), but it works.
First, to move the VMA pointer to RDI:
ffffffff810b5c21: 49 8b 45 70           mov rax,QWORD PTR [r13+0x70]ffffffff810b5c25: 48 8b 80 88 00 00 00  mov rax,QWORD PTR [rax+0x88]ffffffff810b5c2c: 48 85 c0              test rax,raxffffffff810b5c2f: 74 08                 je ffffffff810b5c39ffffffff810b5c31: 4c 89 ef              mov rdi,r13ffffffff810b5c34: e8 c7 d3 b4 00        call ffffffff81c03000 <__x86_indirect_thunk_rax>
Then, to get full control over RDI:
ffffffff810a4aaa: 48 89 fb              mov rbx,rdiffffffff810a4aad: 48 8b 43 20           mov rax,QWORD PTR [rbx+0x20]ffffffff810a4ab1: 48 8b 7f 28           mov rdi,QWORD PTR [rdi+0x28]ffffffff810a4ab5: e8 46 e5 b5 00        call ffffffff81c03000 <__x86_indirect_thunk_rax>
At this point, we can call into run_cmd(), which spawns a root-privileged usermode helper, using a space-delimited path and argument list as its only argument. This gives us the ability to run a binary we have supplied with root privileges. (Thanks to Mark for pointing out that if you control RDI and RIP, you don't have to try to do crazy things like flipping the SM*P bits in CR4, you can just spawn a usermode helper...)
After launching the usermode helper, the kernel crashes with a page fault because the JOP chain doesn't cleanly terminate; however, since that only kills the process in whose context the fault occured, it doesn't really matter.Fix timelineThis bug was reported 2018-09-12. Two days later, 2018-09-14, a fix was in the upstream kernel tree. This is exceptionally fast, compared to the fix times of other software vendors. At this point, downstream vendors could theoretically backport and apply the patch. The bug is essentially public at this point, even if its security impact is obfuscated by the commit message, which is frequently demonstrated by grsecurity.
However, a fix being in the upstream kernel does not automatically mean that users' systems are actually patched. The normal process for shipping fixes to users who use distribution kernels based on upstream stable branches works roughly as follows:
  1. A patch lands in the upstream kernel.
  2. The patch is backported to an upstream-supported stable kernel.
  3. The distribution merges the changes from upstream-supported stable kernels into its kernels.
  4. Users install the new distribution kernel.

Note that the patch becomes public after step 1, potentially allowing attackers to develop an exploit, but users are only protected after step 4.
In this case, the backport to the upstream-supported stable kernels 4.18, 4.14, 4.9 and 4.4 were published 2018-09-19, five days after the patch became public, at which point the distributions could pull in the patch.
Upstream stable kernel updates are published very frequently. For example, looking at the last few stable releases for the 4.14 stable kernel, which is the newest upstream longterm maintenance release:
4.14.72 on 2018-09-264.14.71 on 2018-09-194.14.70 on 2018-09-154.14.69 on 2018-09-094.14.68 on 2018-09-054.14.67 on 2018-08-244.14.66 on 2018-08-22
The 4.9 and 4.4 longterm maintenance kernels are updated similarly frequently; only the 3.16 longterm maintenance kernel has not received any updates between the most recent update on 2018-09-25 (3.16.58) and the previous one on 2018-06-16 (3.16.57).
However, Linux distributions often don't publish distribution kernel updates very frequently. For example, Debian stable ships a kernel based on 4.9, but as of 2018-09-26, this kernel was last updated 2018-08-21. Similarly, Ubuntu 16.04 ships a kernel that was last updated 2018-08-27. Android only ships security updates once a month. Therefore, when a security-critical fix is available in an upstream stable kernel, it can still take weeks before the fix is actually available to users - especially if the security impact is not announced publicly.
In this case, the security issue was announced on the oss-security mailing list on 2018-09-18, with a CVE allocation on 2018-09-19, making the need to ship new distribution kernels to users clearer. Still: As of 2018-09-26, both Debian and Ubuntu (in releases 16.04 and 18.04) track the bug as unfixed:
https://security-tracker.debian.org/tracker/CVE-2018-17182https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-17182.html
Fedora pushed an update to users on 2018-09-22: https://bugzilla.redhat.com/show_bug.cgi?id=1631206#c8ConclusionThis exploit shows how much impact the kernel configuration can have on how easy it is to write an exploit for a kernel bug. While simply turning on every security-related kernel configuration option is probably a bad idea, some of them - like the kernel.dmesg_restrict sysctl - seem to provide a reasonable tradeoff when enabled.
The fix timeline shows that the kernel's approach to handling severe security bugs is very efficient at quickly landing fixes in the git master tree, but leaves a window of exposure between the time an upstream fix is published and the time the fix actually becomes available to users - and this time window is sufficiently large that a kernel exploit could be written by an attacker in the meantime.
Categories: Security

Fabric Resiliency Best Practices

IBM Redbooks Site - Wed, 09/26/2018 - 09:30
Draft Redpaper, last updated: Wed, 26 Sep 2018

This IBM® Redpaper™ publication describes preferred practices for deploying and using advanced Brocade Fabric Operating System (FOS) features to identify, monitor, and protect Fibre Channel (FC) SANs from problematic devices and media behavior.

Categories: Technology

Review: iPhone XS -- amazing screen, fantastic pictures, and more

iPhone J.D. - Mon, 09/24/2018 - 01:16

Last year's iPhone X was, in my opinion, the most significant year-to-year advance in iPhone technology.  Apple found a way to almost defy physics, fitting a larger, beautiful OLED screen into a device that remained the same size in your hand.  Apple also added a second camera lens — a telephoto lens — which Apple previously only found space for on the larger Plus models.  Toss in the speed improvements and various other new features, and it was a major upgrade.  The 2017 iPhone X seemed like it was a 2018 iPhone X that we were somehow seeing a year early.  (And as if to emphasize that point, last year Apple introduced an iPhone 8, and then skipped number 9 to also introduce the iPhone X.)

How do you follow up on an act like that?  Apple actually has some experience in this area.  It adds nice but incremental improvements to the prior year model, and then to indicate that it is a less significant upgrade, Apple adds an "s" to the name.  Hence, Apple has introduced the iPhone 3GS, iPhone 4S, iPhone 5s, and iPhone 6s.  An "s" year iPhone doesn't mean that there are no big new features.  For example, the iPhone 4S added Siri and the iPhone 5S added a way to authenticate without typing a password (Touch ID), and both of those features remain critical parts of the iPhone.  But in an "s" year, hardware changes are typically less noticeable.

That last sentence holds true this year in one way, but doesn't hold true in two other ways.  The iPhone XS, which I purchased, fits the mold of prior "s" year upgrades.  The hardware on the outside looks almost exactly the same, so the real improvements are under the hood.  But in addition, Apple made the iPhone larger in the iPhone XS Max, and Apple made the iPhone less expensive with the iPhone XR.  If you purchase either the iPhone XS Max or the iPhone XR, then you are getting a phone with obvious physical differences from the 2017 iPhone X.  This review focuses on the iPhone XS, but I at the end I also have some comments about the other two new iPhones.

The iPhone X

Before talking about the iPhone XS, I want to say a few words about the iPhone X, because I am sure that most of you who are considering a new iPhone this year are upgrading from a model that is at least a few years old.  Crossing over from an iPhone with a home button to an iPhone with an edge-to-edge screen is a major change.  And at least initially, perhaps not a welcome change.  Many attorneys (including my wife) have told me that they like having a home button; something that you can always press to exit from an app and go back to the main screen.  Additionally, there are real advantages to using Touch ID over Face ID.  For example, your face has to be in front of the camera, so you cannot just reach over to touch your iPhone to unlock it; you need to move the iPhone (or move your face) to the right position.  And while you can discretely unlock an iPhone using Touch ID while you are talking to someone else, the other person will notice if you stop looking at them and start looking at your iPhone.

Nevertheless, I think that the advantage of a larger screen is more than worth it.  I'm reminded of ten years ago, when I heard from countless attorneys who loved the small keyboards on their BlackBerries and Palm Treos, folks who said that they couldn't imagine typing on a flat glass screen.  I would always say that the space used up by a physical keyboard is wasted when you are not typing, resulting in a tiny screen that could be twice as large, allowing you to see more emails and other information.  The same is true today.  When you give up the space dedicated to the home button and the bezels around the edges, you have so much more screen real estate without increasing the size of the device.  I used this picture with my review of the iPhone X, and it sums up why I love, love the larger iPhone X, and now iPhone XS, screen — you get Line 8 and Line 9:

Learning to swipe up from the bottom of the screen instead of pressing a button involves a learning curve, and you do give up something when you move from Touch ID to Face ID.  But I think it is worth it, and I encourage you to keep an open mind about the change.  The large and beautiful screen on the iPhone X and now the iPhone XS is a delight to use, and my enthusiasm hasn't waned one bit even after almost a year of using it.  You can use a device that feels the same size in your hand, but you can see so much more on the screen, and the screen technology itself is so much nicer to look at.  The iPhone has always been about the touchscreen, and for the past year that touchscreen has been amazing.

Better photography

If you skipped over the iPhone X and are now thinking about getting the iPhone XS, one of the big reasons to do so is that you can take much better pictures with the iPhone XS.  Last year's iPhone X already did a great job of taking pictures, but there were circumstances in which it struggled, such as when you had lots of contrast in a picture with both bright and dark areas.

The iPhone XS is really impressive in these circumstances because of technology which Apple calls Smart HDR.  When you are talking about photography, a picture really is worth a thousand words, so here are some examples.  I took some pictures this weekend using both my iPhone X and my iPhone XS, and I think that the differences are pretty remarkable.  If you are using an iPhone even older than the iPhone X, the differences will be even more noticeable.  I did not do anything to correct the color, exposure, etc. in any of these pictures.  I did crop them a little.  In every picture below, the first picture was taken with the iPhone X, and the second picture was taken with the iPhone XS, in both cases using the normal 1x wide angle lens, not the telephoto lens.  You can click on any picture to see a larger version.

In this first example, I'm taking a picture of brick walls with a bright sky in the background.  The sky was bright enough that the contrast overwhelmed the iPhone X.  It is not until you look at the second picture taken with the iPhone XS that you realize that you are supposed to be seeing a roof of a house just over the brick wall.  And the color of the bricks in the iPhone XS picture better matches what my eyes actually saw.

Now let's go to St. Charles Avenue in New Orleans to look at a passing streetcar.  On a bright day, many pictures taken with the iPhone X are hazy, which causes the colors to be more drab.  The iPhone XS does a better job of showing the true colors of the green streetcar with its crimson accents.  You also see more color, and more detail, in the shadow on the grass created by the streetcar.  The text on the side of the streetcar is crisper.  The skin tones on the people are more accurate.  It is just a better picture.

As the streetcar passed me, I took another set of pictures.  Once again, the iPhone X picture is far more hazy, so the colors look worse.  I will admit that there is one small advantage to the haze in the iPhone X picture:  You see rays of light, which is an interesting artistic effect.  But the rest of the picture looks worse.  One noticeable difference:  the sky.  Over and over again in my pictures, I noticed that on a bright day you are far more likely to see the blue in the sky with the iPhone XS.  If you like a blue sky, get an iPhone XS.  (Note to Apple:  feel free to use that marketing line in your advertising.)

I even tried to save the iPhone X picture by using the edit feature in the Photos app to restore some of the green and crimson on the streetcar and the green of the grass that is washed out in the original iPhone X picture.  That helped, but it still didn't look as good as the iPhone XS picture; for example, I still couldn't see the blue of the sky.

As the streetcar started to head away from me and towards the French Quarter, I took one last set of pictures.  With the streetcar taking up less of the screen, I was finally able to see some of the blue sky even in the iPhone X picture.  But the shadow on the side of the streetcar and on the ground next to the streetcar was too much of a challenge for the iPhone X, resulting in a darker picture with fewer details.  But the iPhone XS handled this with aplomb. 

I think that these streetcar picture examples are informative because they reflect many of the pictures that I take with an iPhone in real life.  The times when I think to myself something like: "Oh cool, there is a streetcar, let me take a quick picture as it passes."  Because your iPhone is with you so often, the convenience makes it the perfect camera for those quick, unplanned moments in life in which you want to quickly snap a picture of friends or family or the world around you. 

Professional photographers use equipment and techniques to get the right amount of light for a photograph.  But in real life, you don't have all that fancy stuff, and often you want to take a picture when the light isn't that great.  As iPhone low light photography has improved every year, you are more likely to get a great picture to remember that special moment.  It comes as no surprise that the iPhone XS also does a better job with low-light photography, and thanks to the advanced processor, it is a big leap forward.  John Gruber of Daring Fireball has some excellent examples of both photos and videos in low light in this set on Flickr.  The video examples near the bottom are particularly impressive.

One thing that you notice in low light photos in which there is a source of light is that the source of light itself looks much better.  In the following pictures, notice how you can actually see the shape of the flame in the iPhone XS picture.  It is all just a blob in the iPhone X picture:

The iPhone XS also does a great job with videos.  I took some videos of my daughter playing soccer on Saturday, and they came out great.  The grass is green, the sky is blue, and the images are crisp.  Jason Snell of Six Colors may have figured out the reason that the video looked so good when he tweeted the following on Friday:  "Maybe the most bananas thing I've learned about iPhone XS is that if you shoot 4K 30fps video, it actually shoots 60fps with every other frame stepped up/down, and then stitches the frame pairs together on the fly to create extended dynamic range."  By the way, if you enjoy using your iPhone to take videos, I strongly encourage you to consider getting the Glif + Hand Grip by Studio Neat, which I reviewed last year.

Portrait mode photographs are pretty neat on the iPhone XS.  You can adjust the amount of blur in the background, an effect called bokeh, commonly seen in pictures taken with high-end SLR cameras.  I tried this with some pictures of my daughter, and it was nice to have this level of control.  As you blur the background more, you place more emphasis on the subject of the photo, and then you get to decide how much blur is too much.  Apple did a nice job with this.

Every year, there is new iPhone that takes better pictures, but this year Apple did an especially good job with the improvements.  What is most fascinating to me is that while the iPhone XS does feature a slightly better wide angle lens (the zoom lens is the same as the iPhone X), the picture quality is often substantially better simply because the processor inside of the iPhone is so much faster and more sophisticated.  The iPhone X was already a good camera, but the iPhone XS is much better.  If you take pictures with your iPhone, this is the iPhone for you.

Performance

Speaking of the processor improvements, the new CPU is faster and more energy efficient, and it includes a neural engine which allows the iPhone to handle even more sophisticated tasks.  Updating from an iPhone that is two or more years old to the iPhone XS result in a noticeable speed increase, with everything seeming much more responsive.  And even as compared to last year's iPhone X, the iPhone XS does a much better with complicated operations.  For example, the free augmented reality LightSpace app is much more fluid on an iPhone XS than on an iPhone X.  I rarely play games with sophisticated 3D graphics, but I have no doubt that those perform even better on the iPhone XS.

I haven't yet able to test Gigabit-class LTE, a faster version of 4G as 5G is still being developed, which the iPhone XS supports.  My carrier, AT&T, is bringing this service to New Orleans this year, but apparently, it isn't live yet.  In cities where it is available, Gigabit-class LTE should be about twice as fast as current LTE.

The iPhone XS Max and the iPhone XR

I stopped in my local Apple Store this weekend to see what the new Apple Watch Series 4 looks like.  (It looks awesome, and the one I ordered should be delivered soon.).  I also checked out the iPhone XS Max.  It looks just like an iPhone XS, only bigger, which makes everything easier to see.  However, it felt ridiculously large in my hand.  For me, the advantage of a larger screen isn't worth the tradeoff of the device being so much harder to hold, not is it worth losing the ability to use the iPhone with just one hand.  Having said that, soon after I tried out the iPhone XS Max, I ran into someone telling me how much he likes his iPhone 8 Plus, which is about the same size, so I know that there are people who like this form factor.  If that describes you, then the iPhone XS Max is a major leap forward because you get a crazy large screen in a device size that you are already used to holding.

If you want to spend less money but get most of the features of the iPhone XS, then the iPhone XR might be perfect for you.  In my September 13, 2018 post, I listed everything that you give up with the iPhone XR.  The feature that I would most miss is the telephoto lens, but if that isn't important to you, the iPhone XR looks like a very compelling device.  You can order an iPhone XR starting October 19, and devices ship and are available in stores a week later.

Misc.

There are a few other things worth knowing about the iPhone XS and the iPhone XS Max.  First, they come in a new color:  gold.  It is sort of a mocha/copper type of gold.  It doesn't appeal to me, but I'm sure that it will appeal to many folks.

Second, Apple says that the screen is even more durable.  Vanessa Hand Orellana of CNet did some drop tests, and the results were promising:  "I've done my fair share of drop tests in my time at CNET, and I've never come out of one without a broken phone.  Until now.  The iPhone XS didn't crack."  Hopefully none of us need to "test" this ourselves.

Third, the iPhone has dual-SIM support using a second eSIM.  If you travel intentionally, this could be very useful.

Fourth, Face ID is a little better on the iPhone XS versus the iPhone X.  In my side-by-side tests, sometimes it worked just as well, but other times Face ID worked better on the iPhone XS.  Every little bit helps, but so far this has not been a major improvement.  One important caveat — Face ID is a technology that is supposed to improve over time.  Is it possible that I'm really comparing an iPhone X with a year of learning my face against an iPhone XS which has only had a weekend, and will get even better over time?  I'm not sure, but perhaps.

Fifth, the sound is improved.  The speakers are much better than the iPhone X, with wider sound, so much so that the first time I played a video I was actually startled that this sound was coming from my iPhone.  And when you record video, the iPhone XS now records in stereo, so it sounds better.  Check out those John Gruber videos I linked above to see what I mean.

Sixth, the iPhone XS is more water resistant.  I didn't test this with my expensive new phone, but as I described in more detail in my September 13, 2018 post, Apple has increased the IP Code rating from IP67 to IP68.  And that's better.

Conclusion

Unless you are an early adopter who loves using the latest and greatest technology, I don't recommend upgrading from an iPhone X to an iPhone XS unless you want the larger size of the Max or if photography is really important to you.  But for everyone else, the iPhone XS is amazing, combining everything I loved about the iPhone X with even more nice features. 

With the large and beautiful screen of the iPhone XS, you can see more information on the screen at one time.  Whether you are reading emails, looking at a document, doing some quick legal research, or looking at a PDF file, you can be more productive than ever with the iPhone XS.  Sure, there will still be times when you want to instead reach for an iPad or a computer, but I have been able to do more with my iPhone X for the last year and the same will be true with the iPhone XS.  When you are done with your work, the iPhone XS is the perfect device for the rest of your life, especially if that involves taking pictures.

It is also nice that you get more choice this year.  If you want a crazy large screen, get the iPhone XS Max.  If you want to shave off some of the features that you can live without and save some money, get the iPhone XR next month.  But for the best all-around phone, I think that the iPhone XS hits the sweet spot.

My past year of using an iPhone X was my favorite year ever of using an iPhone.  I can already see that the iPhone XS is going to be even better.  If you are ready for an upgrade, you are in for a treat. 

Categories: iPhone Web Sites

Pages

Subscribe to www.hdgonline.net aggregator