Feed aggregator

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

In the news

iPhone J.D. - Fri, 09/21/2018 - 02:37

Many of Apple's newest products go on sale today, including the iPhone XS, the iPhone XS Max, and the Apple Watch Series 4.  (The iPhone XR will be available in stores starting October 26.)  Using the Deliveries app on my current iPhone, I've been monitoring my iPhone Xs this week as it went from Shenzhen, China to Anchorage, Alaska to Louisville, Kentucky, and as I type this it should soon be on an early Friday morning plane to New Orleans.  My own travel over the last few days has been far less interesting because my days have mostly been consumed with drafting appellate briefs.  This has been a crazy busy week in the world of iOS-related stories, thanks to the new version of iOS and watchOS that came out earlier this week, the numerous reviews written by folks who got early looks at the new iPhones and new Apple Watch, and tons of app updates to take advantage of the new features in iOS 12.  I've tried to select some of the most interesting items to feature in this collection of the news of note from the past week:

  • California attorney David Sparks posted a video review of the Elevation Labs Draft Table, a strong and sturdy stand that can tilt your iPad to various angles.  I like that it can be adjusted to different angles.  In my law practice, I mostly use my iPad Pro in two different angles.  First, when I taking handwritten notes, and sometimes when I am annotating documents, I prefer a slight tilt, and the Apple Smart Cover is perfect for that.  Second, when I am mostly reading things on the screen and doing some light annotation, I prefer a more upright position, and for that, I love the strong and sturdy Simplex Tablet iPad Stand by Thought Out (my review).  The Simplex only has one viewing angle, but I find that it is the only angle that I need other than the one I get with my Apple Smart Cover.  Whatever product you use, I think that getting your iPad in the right angle for the work you are doing is a key part of being more productive with an iPad in a law practice.
  • Suzanne Barlyn of Reuters reported this week that John Hancock, one of the oldest life insurers in North America, will stop underwriting traditional life insurance policies and instead will only offer policies that adjust the life insurance premiums based upon how much you exercise, as measured by a wearable device such as the Apple Watch.
  • To get you ready for your new insurance policy, let's start with some news items about the Apple Watch.  I wasn't surprised to see reviews of the new Series 4 Apple Watch this week by traditional media outlets, but I was surprised to see a review by Jon Hamm — yes, that Jon Hamm, of Mad Men — who talked to John Lonsdale of Men's Journal about his thoughts on the new device.  Hamm says:  "It’s not as chunky on your wrist, but the face is bigger, so if you have fat fingers like me, you can press those little buttons and it all works well."
  • Stephen Pulvirent of Hodinkee, who specializes in reviewing expensive watches, wrote a great review of the Series 4 Apple Watch.  The video which accompanies the review is beautifully-produced and informative.  Given his job, it is no surprise that he concludes by saying that he still plans to wear his Rolex most days, but he admits that he is going to keep a Series 4 charged and ready to go for certain days, and says that "Apple is on a trajectory where each new version of the Apple Watch gets more useful, cooler, more fun to wear, and we're on a path where at some point, it's just going to become indispensable.  And with the Apple Watch Series 4, Apple is showing us that that future is closer than we thought."  I've never owned a Rolex or other super-expensive traditional watch, and because I love wearing an Apple Watch so much, I'm quite certain that I never will.
  • Liz Plosser of Women's Health says that the new Apple Watch is a "powerful health and fitness accessory."
  • The new Series 4 Apple Watch looks amazing, but almost every Apple Watch model got better this week thanks to watchOS 5.  Alex Guyot wrote a comprehensive review of watchOS 5 for MacStories.
  • The other new Apple hardware in the news this week was the iPhone XS.  Rene Ritchie of iMore wrote a comprehensive review of the iPhone XS.
  • David Pogue of Yahoo reviews the new iPhone XS and, as always, includes one of his funny and goofy videos to go along with it.
  • Travel photographer Austin Mann shows that the new iPhone XS does a great job of capturing what people actually see with their eyes, thanks to the HDR improvements.
  • Former White House photographer Pete Souza took some amazing pictures for DailyMail with the new iPhone XS in Washington, D.C.
  • Almost every model of the iPhone got better this week thanks to iOS 12.  Jason Snell of Six Colors explains the improved search feature in Photos in iOS 12 which allows you to, for example, see pictures you have taken of dogs, and then refine that to just see pictures of dogs in the snow.
  • I love, love, love, love, love the deep integration of 1Password into iOS 12.  Ryan Christoffel of MacStories shows off how it works.  If you still don't use a password manager, now that iOS 12 is out, you really don't have an excuse.
  • Overcast was already my favorite podcast app, but it is now so much better with iOS 12 and watchOS 5.  I particularly love the ability to listen to podcasts using just my Apple Watch and my AirPods, which is great for doing tasks around the house without having to carry around an iPhone.  I haven't yet used this combination when walking or jogging outside, but I look forward to trying that out soon.  Zac Hall of 9to5Mac wrote a good review of what is new in Overcast on the iPhone and Apple Watch.
  • It's going to take me months to get my arms around the new automation that is now possible thanks to Siri Shortcuts and the Shortcuts app in iOS 12.  But as if that wasn't enough, Federico Viticci of MacStories figured out how to trigger IFTTT applets using Siri and the Shortcuts app, which gives you the ability to trigger hundreds of additional services and devices such as a Sonos, a Roomba, an online document, and more.
  • Steven Levy wrote a great article for Wired about the history of Apple's Infinite Loop campus, based on interviews with tons of folks connected with Apple.
  • And finally, here is a video produced by Apple which shows off the major new features of the iPhone XS in just one minute:

Categories: iPhone Web Sites

Initial reviews of the new iPhone XS

iPhone J.D. - Wed, 09/19/2018 - 02:12

A few days ago, Apple provided select members of the press with an iPhone XS and an iPhone XS Max so that they could post a review yesterday, shortly before the 2018 versions of the iPhone officially go on sale this Friday.  Review units were given to John Gruber of Daring Fireball (review), Matthew Panzarino of TechCrunch (review), Joanna Stern of the Wall Street Journal (review), Nilay Patel (a former practicing attorney) at The Verge (review), Raymond Wong of Mashable (review), John Paczkowski of BuzzFeed (review), Brian X. Chen of the New York Times (review), Lauren Goode of Wired (review), Todd Haselton of CNBC (review), and Scott Stein of CNET (review).  Here are my major takeaways from what these folks wrote after using the new iPhones for the last few days:

  • Many people found the camera to be much better than the iPhone X.  John Gruber was particularly impressed, and the photos that he provided as examples show that the iPhone XS produces noticeably better pictures than the iPhone X in situations in which HDR makes a difference — pictures in which you have both light and dark spots.  If you are taking pictures outside on a nice day, this may not matter very much.  But if you are inside with less light, this can make a big difference.  Similarly, Matthew Panzarino provided some stunning sample pictures and said that he thinks Apple "dramatically undersold how much improved photos are from the iPhone X to the iPhone XS.  It’s extreme, and it has to do with a technique Apple calls Smart HDR."  And Nilay Patel says that the "camera upgrades on the XS over the X are significant. The XS makes the X camera look terrible most of the time."  (Patel still prefers the pictures taken by the Google Pixel 2, but when I looked at his sample pictures, I preferred the iPhone XS picture over the Google Pixel 2 picture every time.  Just goes to show you that there is certainly a subjective element to an art like photography.)
  • On the other hand, some of the other reviewers were less impressed with the camera.  For example, John Paczkowski said that the iPhone XS pictures were better than ones he took with the iPhone X, and yet it was still "pretty hard to tell" the difference.  And Lauren Goode said that pictures taken with the iPhone XS were only "slightly improved from the iPhone X photos," although she did see a more noticeable improvement in portrait mode photos.
  • Considering that you can actually see how much better the pictures are in the reviews posted by folks like Gruber and Panzarino, I find myself believing that the iPhone XS camera really is a big improvement over the iPhone X, but only some of the time, and perhaps other reviewers were taking pictures in conditions in which the improvement was less noticeable.  As Joanna Stern noted:  "The smart HDR feature and new sensors did make for a more even and clear photo when shooting almost directly into brighter lights—plus crisper, more colorful low-light shots—but overall my photos looked similar to the ones I’ve taken with the X."  But she also found that autofocus and launching the camera is much faster.
  • If you like the idea of a bigger phone, the iPhone XS Max is a very nice bigger phone.  If you previously used a Plus model of an iPhone, then you know whether that type of size is too large for your hands.  But many reviewers, such as Brian X. Chen, said that after trying both, they preferred the iPhone XS size.  If you want an interesting perspective, check out the video at the top of the review by Joanna Stern in which she shows what an iPhone XS Max looks like in the hands of basketball player Gheorghe Muresan.
  • Only one reviewer, Todd Haselton, tested the improved water resistance of the iPhone XS.  He said that he put the iPhone XS "in a fountain about 1 foot deep for five minutes and it was totally fine after I took it out."
  • The screen on the iPhone XS supposed to be more durable.  Nevertheless, Joanna Stern reported that the screen on her iPhone XS Max cracked after “a minor fall onto wood."
  • The built-in speakers are noticeably better.  Raymond Wong says that there is more separation between the left and right channels.  And many reviewers noted that the sound is noticeably louder.
  • The iPhone XS is noticeably faster.  Raymond Wong notes that complicated games like Fortnite play better on the iPhone XS.  And Joanna Stern noted that even "[e]veryday actions are faster too — even just pressing the reply button in the Gmail app."  Several folks noted that Face ID is also faster and thus works better.
  • If you use a wireless charger, it will work better with the iPhone XS because the iPhone XS is more forgiving about where you place the iPhone on the charger.

My iPhone XS is supposed to be delivered this Friday.  In light of these initial reviews, I'll definitely be taking lots of pictures this weekend to see what I think about the improvements.  And I hope that I notice the speed increases in everyday actions, as Joanna Stern pointed out.

Categories: iPhone Web Sites

IBM Spectrum Scale Security

IBM Redbooks Site - Tue, 09/18/2018 - 09:30
Redpaper, published: Tue, 18 Sep 2018

Storage systems must provide reliable and convenient data access to all authorized users while simultaneously preventing threats coming from outside or even inside the enterprise.

Categories: Technology

iOS 12 will be released today, along with watchOS 5

iPhone J.D. - Mon, 09/17/2018 - 01:05

Today, Apple will release as a software update the latest version of the operating system for the iPhone and iPad, iOS 12.  Apple previewed the features of iOS 12 three months ago, and you can click here to read what is new.  Note that I discussed the new version of FaceTime in that post, but Apple has decided to wait a little bit longer before rolling out the group FaceTime feature.

The feature that I am most looking forward to is Siri Shortcuts.  I like the Workflow app, and now that it is built-in to the operating system it will be so much more powerful.  I like that iOS 12 will recommend shortcuts to you, making this feature accessible to everyone.  But I'm especially interested to see all of the great shortcuts that power users will be able to dream up and share.

Moreover, when apps are updated to support shortcuts, they can become much more powerful.  Here's a great example.  I often wear my AirPods to listen to a podcast or music as I am walking through an airport to catch a flight.  Wit the TripIt app installed on my iPhone, I can say "Hey Siri, upcoming flight" and TripIt will (1) tell my my next flight number such as Delta 123, (2) tell me how long I have before the flight departs, (3) tell me the gate number, and (4) tell me the flight's status.  (Note that #4, flight status, is only available if you pay for the TripIt Pro service, but the other features work for everyone.)  That is precisely the information that I want as I'm walking through the airport, and if I'm wearing my AirPods, Siri can just talk to me without me needing to look down at my iPhone screen.  And this is just one example of what the TripIt app can do with shortcuts.  And TripIt is just one of countless apps that will be updated to support shortcuts.  This is cool stuff.

I'm also looking forward to the improvements to notifications.  In iOS 12, they are even easier to manage and organize.

It's always a good idea to backup your device before you install a major new update such as iOS 12.  Last night, I backed up my iPhone and my iPad to my iMac so that I would be ready.  The update is typically available around 10am Pacific / 1pm Eastern, and I always recommend that you wait a few hours before updating because there have been a few times in the past when Apple had to pull an update shortly after release because a bug was discovered. 

watchOS 5

In addition to iOS 12, Apple is also releasing watchOS 5 today.  I discussed the major new features in this post.  There are fitness improvements, the new Walkie-Talkie feature, support for Siri Shortcuts, podcast support, improved notifications, and more.  Thus, if you already have an Apple Watch on your wrist, today it gets better.

Categories: iPhone Web Sites

In the news

iPhone J.D. - Fri, 09/14/2018 - 03:29

Early this morning, Apple started taking orders for the iPhone XS, the iPhone XS Max, and the newly redesigned Series 4 version of the Apple Watch.  I placed orders for an iPhone XS and the Series 4 Apple Watch.  At the time that I placed my orders, the delivery date for the iPhone XS and the aluminum version of the Series 4 Apple Watch was September 21.  However, I ordered the Stainless Steel version of the Apple Watch, and even though I placed my order immediately when the Apple Store opened, my Stainless Steel model has a delivery date of September 28 to October 2.  For folks looking to get the iPhone XS Max, I see that it did not take very long for delivery dates to go past September 21 for many of the configurations.  It will be interesting to see what kind of demand there is for all of the new products announced this week and how far back the delivery dates start to slip.  And now, the news of note from this busy week in the iPhone and Apple Watch world:

  • One of the notable new features in the Series 4 Apple Watch is the the ability to perform an EKG.  Christina Farr of CNBC has an excellent explanation of this new feature and what it can do.
  • In addition to selling AppleCare+ for the iPhone, Apple has started a new insurance program called AppleCare+ with Theft and Loss.  As the name implies, this program will cover two incidents of accidental damage, theft, or loss, although there is a deductible.  Get more information on the Apple website.
  • Christina Passariello of the Washington Post talked to Apple's design chief, Jony Ive, about the new Apple Watch.
  • Last year, Apple announced the AirPower charging pad, but it still hasn't been released, and most references to it were removed from the Apple website this week.  Mike Wuerthele of AppleInsider has some theories on why.
  • Readdle makes some of the most useful apps for attorneys including Scanner Pro (which I use on my iPhone every week, and sometimes every day) and PDF Expert.  Killian Bell of Cult of Mac reports that the company's apps have now been downloaded 100 million times.  Congrats, Readdle!
  • You can now use ApplePay at nearly all 7-Eleven stores, as reported by Juli Clover of MacRumors.
  • It is widely known that Apple is planning to open its own video streaming service in the future.  Ben Lovejoy of 9to5Mac reports that Apple just won its first Emmy award for Apple-produced content, this one for Carpool Karaoke.  I suspect that this won't be Apple's last Emmy for a TV show.
  • If you own an Apple HomePod, it's going to get better next week.  As Ryan Christoffel of MacStories reports, the device will gain support for multiple timers, phone calls, and the ability to play a song if you don't know the name but you do know a line of the lyrics.
  • Geoffrey Fowler of the Washington Post discusses the challenges with recycling consumer electronics such as iPhones and iPads containing lithium-ion batteries.
  • In what almost seemed like a response to that article by Fowler, Apple's keynote featured a presentation by Lisa Jackson, Apple's Vice President in charge of environment, policy and social initiatives.  (She is also the former administrator of the EPA.)  Horace Dediu of Asymco discusses the most interesting aspects of Jackson's presentation.
  • And finally, Apple released lots of videos in connection with this week announcements, but today I'm just picking one that is silly and fun.  The opening video for this week's keynote address features someone running across Apple's new campus in Mission: Impossible style.  (As Roger Fingas of AppleInsider points out, Apple took some liberties for the path used by this runner.)  The video is entertaining, and also gives you some good views of Apple's new campus:

Categories: iPhone Web Sites

Why lawyers will love the iPhone Xs

iPhone J.D. - Thu, 09/13/2018 - 02:41

There have been four times in the past when Apple has debuted a major new iPhone with a new hardware design, and then the next year has debuted an "s" model:  the iPhone 3GS, iPhone 4S, iPhone 5s, and iPhone 6s.  These "s" models contain new features, sometimes even new hardware features, but the main emphasis seems to be on deeply improving the prior year's model.  Many lawyers have told me that they buy a new iPhone every two years and prefer to buy on the "s" year because that is when Apple really perfects each generation of iPhone.  Yesterday, Apple debuted the new iPhone XS (pronounced "ten ess"), and it fits this model perfectly.  The iPhone XS answers the question of what can we do if we take the basic hardware of the iPhone X, with that beautiful OLED edge-to-edge screen, and then deeply improve it.

One of the most notable ways that Apple has improved upon the iPhone X model is by releasing three different versions of the iPhone XS.  The main model adds the typical types of improvements that we would expect for an "s" model.  But Apple also introduced two other versions of the iPhone XS:  one for people who want an even bigger screen called the iPhone XS Max, and one for people who to save some money but still get most of the good stuff called the iPhone XR.  Add to this that many of the older iPhone models are still available for sale at cheaper prices, and there is truly an iPhone for everyone.

I'll start by discussing the improvements over the iPhone X that exist in both the main model and the larger Max model — and most of these improvements also exist in the cheaper iPhone XR model.

Performance

For a while now, Apple has been designing its own CPUs, allowing the company to create amazing processors which make the iPhone more powerful every year.  For the 2018 iPhone, Apple has added the new A12 Bionic chip.  As you would expect, this new CPU is faster and more energy efficient than prior models.  But to give the A12 an additional boost, Apple added a the Neural Engine, a part of the CPU dedicated to the task of machine learning. 

Thanks to the Neural Engine, the iPhone XS can recognize patterns, make predictions, and learn from experience, and do all of this while performing five trillion operations per second.  In other words, the iPhone is smarter and faster.  The Neural Engine is especially useful for the camera (more on that below), but also allows the iPhone XS to perform more sophisticated computations.  Augmented Reality should be significantly better on the iPhone XS. 

Obviously this makes the iPhone better for CPU-intensive apps like sophisticated games.  But even if you are just drafting an email to a client, surfing the web, or looking at photos, a faster iPhone is a more responsive iPhone, which always makes an iPhone more pleasant to use.

Speaking of making the iPhone faster, the iPhone XS also adds support for Gigabit-class LTE, a faster version of 4G as 5G is still being developed.  My carrier, AT&T, currently has Gigabit LTE in 141 markets.  Gigabit LTE should be about twice as fast as 4G, up to 400 Mbps.  In the real world, I typically see LTE download speeds of around 150 Mbps where I live in New Orleans, whereas if I am close to the Wi-Fi router in my house I see wireless download speeds from my cable modem of around 330 Mbps.  I'll be curious to see if Gigabit LTE is just as fast as Wi-Fi at my house — and significantly faster when I'm not close to the Wi-Fi router — after I upgrade to the iPhone XS.

Camera

It is truly amazing how far the camera on the iPhone has come in the last decade.  Apple says that the newest iPhone has the best camera yet.  It looks like there are only minor improvements in the camera hardware.  Just like the iPhone X, the iPhone XS has two 12 megapixel cameras on the rear, one of which is a wide-angle f/1.8 lens and one of which is a telephone f/2.4 lens.  I love having that telephoto lens on my iPhone X, and if you haven't used an iPhone with this feature before, you'll love it.  There are so many times that I am taking a picture with my iPhone and I want to get closer — such as when I'm taking a picture of my daughter kicking the soccer ball when she is across a soccer field from me.  For both pictures and video, that telephoto lens is a nice feature.

The main thing that is new for the iPhone XS in terms of taking pictures is that the CPU features an improved image signal processor which does a heck of a lot more   As Apple noted yesterday, what really makes the iPhone camera better is the computational photography.  The new the iPhone XS performs up to a trillion operations on every photo you take.  For example, the iPhone XS adds a feature that Apple calls Smart HDR, an improved version of HDR photography.  Apple VP Phil Schiller describes it this way: 

So let's say you're taking a picture and the camera recognizes you're shooting a subject and the subject is moving.  You go to press down on the shutter and you get a picture instantly.  It's called zero shutter lag.  What the A12 Bionic is actually doing is shooting a four-frame buffer so it can capture that critical moment.  But the A12 Bionic is doing even more than that.  It's also capturing secondary inter-frames at the same time.  And those inter-frames are shot at a different exposure level to bring out highlight details.  And it's doing more than that.  It's shooting a long exposure so it can get better shadow detail as well.  And when you're taking that picture it's analyzing all of those, finding out how to match up the best parts of each and merge them into one perfect photo.  That's Smart HDR.  It is a breakthrough, and it makes taking photos easier than ever to get beautiful results.

Apple also showed off a cool new feature when taking Portrait Mode photos — photos in which the subject of your picture is in focus but the background is blurred, similar to the bokeh effect you get with a high-end SLR camera.  There is now a slider to adjust the amount of blurring in the background, so you can decide if you want to see some of the background details, or if you want your subject to really stand out.

Although I normally think of using the camera to take pictures, the front-facing camera is also critical for Face ID.  Apple says that thanks to the advanced A12 Bionic CPU, Face ID is faster and works better on the iPhone XS.  It would be great if this was a noticeable improvement, and I can't wait to find out for myself.

Dual SIM

If you travel internationally with your iPhone, it is sometimes useful to get a different SIM card when you are in another country so that you can avoid expensive roaming charges.  The iPhone XS has a traditional SIM card but also supports a second eSIM.  When carriers support it — and Apple announced that many are on board — you'll be able to use two SIMs at the same time, and the iPhone will intelligently switch between them depending upon the circumstances.  Thus, you should be able to use a cheaper data plan in another country while still receiving phone calls when people call your normal phone number.

More waterproof

I'm sure that Apple would prefer that you not dunk your iPhone into the ocean.  But over time the iPhone has become more resistant to water, and this year the improvement is enough for Apple to increase the IP Code from IP67 to IP68.  The first number refers to how dust-proof the device is, and the iPhone X was already at 6, which is the highest.  But the increase from 7 to 8 is a noticeable increase in liquid ingress protection, to use the technical words.  With 7, a device can go up to 1 meter deep for up to 30 minutes.  With the 8 rating, Apple says that the iPhone XS can go up to 2 meters deep for up to 30 minutes.

Apple isn't advertising the iPhone XS as something you are going to use on your next snorkeling trip as an underwater camera.  Having said that, there are plenty of IP68 cameras being sold on Amazon which specifically advertise themselves as being waterproof and designed for underwater photography.  In part, this is because there is a wide range of ingress protection which all falls under IP68, but I suspect that if you wanted to be daring and take an underwater picture with an iPhone XS, you may not damage your phone at all.

More importantly, if you accidentally drop your iPhone XS in liquid, there is a good chance that you can just let the phone dry out and then it will be fine.  Yesterday, Apple VP Phil Schiller said that the iPhone XS was tested in many liquids, including orange juice, tea, wine, and even beer.

iPhone XS Max

Before the iPhone X, I felt like I had an impossible desire.  I wanted a larger screen, but I didn't want the iPhone to be any larger so that I could continue to use it without stretching my hand too much.  The solution, as the iPhone X showed us, was to reduce the bezels so that you get more screen space than a Plus model inside of hardware that is the same size as a non-Plus model.

But there are some folks out there who don't mind the larger size of the Plus model, and for those folks, Apple has created the iPhone XS Max.  The iPhone XS Max is about the same size as an iPhone 8 Plus, but because of the edge-to-edge design, you get a larger screen.  While the iPhone XS has a 5.8" screen, the iPhone XS Max has a 6.5" screen.  That's not that far off from an iPad mini, which has a 7.9" screen.  While the iPhone XS has a 2436-by-1125-pixel resolution, the iPhone XS Max has a  2688-by-1242-pixel resolution.  (Both are at 458 ppi.)

In terms of physical size, the iPhone XS is 5.65" x 2.79" while the iPhone XS Max is 6.20" x 3.05".

iPhones with a Plus-size screen have been around for a while now, so I suspect that you already know whether or not you are someone who minds the larger hardware size.  If the larger size isn't too big for your pocket or purse, then spending an extra $100 for the iPhone XS Max might be perfect for you.

iPhone XR

If you like the idea of the iPhone XS but you don't want to spend $999 and up for the iPhone XS or $1099 and up for the iPhone XS Max, you'll want to consider the iPhone XR.  Apple didn't say what the "R" stands for, but I presume the idea is that it is one step below "S" and that sounds about right.  The iPhone XR has almost all of the new features that I mentioned above, plus almost all of the features which have made the iPhone X so great.  However, the starting price is $250 less than the iPhone XS:  $749.

Here is what you lose by saving that $250 over the iPhone XS:

  • Display.  Instead of the beautiful high-resolution OLED display with its rich colors and deep blacks, you get an LCD screen, which is the type of screen which Apple used to always offer before the iPhone X.  Apple says that the LCD screen in the iPhone XR is particularly good, but it still won't look as good as an OLED screen.  And while the iPhone XS can show HDR video, much like newer high-end TVs, the iPhone XR cannot.
  • 3D Touch.  You cannot push harder on the screen to bring up different options.  As a workaround, Apple says that you can tap and hold down on the screen for a certain amount of time to trigger the same options — not unlike the way it works on an iPad — and Apple even adds some haptic feedback to reinforce that you are using the substitute for true 3D Touch.
  • Size.  The iPhone XR is actually slightly larger than the iPhone XS with a 6.1" screen, but it is definitely smaller than the iPhone XS Max with its 6.5" screen.
  • Camera.  You only get one camera on the back, so you don't get the telephoto lens.
  • Less waterproof.  The IP rating is IP67, similar to the iPhone X.
  • LTE.  You just get regular LTE, not Gigabit-class LTE.

Having said that, it is not all compromises with the iPhone XR.  You also get one feature that you don't get with the iPhone XS (or the iPhone XS Max):  more colors.  While the iPhone XS comes in silver, space gray, or gold, the iPhone XR comes in blue, white, black, yellow, coral, and red.  And I understand from folks who saw the new iPhone XR in person yesterday that the colors are quite vibrant.  Keep in mind that if you are going to keep your iPhone in a case the whole time, you might not notice the color very much.

Conclusion

The new 2018 iPhones look to be great for any lawyer, or anyone else who is looking to get work done with an iPhone.  With the large, edge-to-edge screen, you can see even more of your documents, your email, etc., and the faster speed allows your iPhone to help you get your work done without getting in the way.  And thanks to the three different models, you can now decide whether you want to pay $250 less to give up a few features that might not even matter to you, or pay $100 more for an even larger screen. With all models offered in 64 GB, 256 GB or 512 GB capacities, you can decide how much space you want. (The 256 GB model is $150 more than the base price 64 GB model, and then 512 GB model is $350 more than the 64 GB model.)  And since I presume that you will also use your iPhone for non-work purposes, such as taking pictures of the kids, playing games, or using the latest Augmented Reality app, the new 2018 models are even better at those tasks.

If you currently use an iPhone X, you probably won't want to upgrade unless you enjoy having the latest and greatest.  But if you currently use an older iPhone, then you'll love using the iPhone X form factor, and as a bonus for waiting an extra year for the "s" model, you can get an iPhone which is significantly improved over the iPhone X with more options on size and price.

What am I going to get?  My current iPhone X typically has about 150 GB in use, so I know that the 64 GB model is not enough for me, and the 256 GB sounds just right.  I don't like a larger phone, but I do want that amazing OLED display.  Thus, I plan to get the iPhone XS in the 256 GB capacity, probably in space gray.

Apple starts taking orders tomorrow, September 14th, and devices will begin shipping on September 21st, for the iPhone XS and iPhone XS Max models.  If you want the iPhone XR, you can order starting October 19, and devices ship a week later.

Categories: iPhone Web Sites

How to Use IBM Cloud Object Storage When Building and Operating Cloud Native Applications

IBM Redbooks Site - Wed, 09/12/2018 - 09:30
Redpaper, published: Wed, 12 Sep 2018

This IBM® Redpaper™ publication presents a series of tutorials for cloud native developers just getting started with IBM Cloud™ and IBM Cloud Object Storage.

Categories: Technology

IBM Power Systems LC921 and LC922: Technical Overview and Introduction

IBM Redbooks Site - Wed, 09/12/2018 - 09:30
Redpaper, published: Wed, 12 Sep 2018

This IBM® Redpaper™ publication is a comprehensive guide that covers the IBM Power Systems™ LC921 and LC922 (9006-12P and 9006-22P)) servers that use the current IBM POWER9™ processor-based technology and supports Linux operating systems (OSes).

Categories: Technology

New iPhone (and more) to be announced today

iPhone J.D. - Wed, 09/12/2018 - 00:31

Today at 10am Pacific / 1pm Eastern, Apple will give a keynote presentation at the Steve Jobs Theater, part of Apple's new Apple Park campus in Cupertino, CA.  We will definitely see the 2018 versions of the iPhone, and I expect to see a new Apple Watch.  I'm sure that Apple will also say something about iOS 12, which Apple first previewed this past June and which I suspect will be released in the next week or so.

Other than that, I'm not sure what Apple will announce.  For example, I expect to see a new iPad Pro this year, but I don't know if we will see it today.  Sometimes Apple announced a new iPad and new iPhone at the same time, other times Apple holds back the iPad announcement until the next month.

Finally, it is always fun when there are surprise announcements, so I hope that something interesting is announced today that I wasn't expecting at all.

If you want to see the announcements live as they happen, click here to watch a live stream from the Apple website.

 

Categories: iPhone Web Sites

Turning Data into Insight with IBM Machine Learning for z/OS

IBM Redbooks Site - Tue, 09/11/2018 - 09:30
Redbook, published: Tue, 11 Sep 2018

The exponential growth in data over the last decade coupled with a drastic drop in cost of storage has enabled organizations to amass a large amount of data.

Categories: Technology

OATmeal on the Universal Cereal Bus: Exploiting Android phones over USB

Google Project Zero - Mon, 09/10/2018 - 12:18
Posted by Jann Horn, Google Project Zero
Recently, there has been some attention around the topic of physical attacks on smartphones, where an attacker with the ability to connect USB devices to a locked phone attempts to gain access to the data stored on the device. This blogpost describes how such an attack could have been performed against Android devices (tested with a Pixel 2).
After an Android phone has been unlocked once on boot (on newer devices, using the "Unlock for all features and data" screen; on older devices, using the "To start Android, enter your password" screen), it retains the encryption keys used to decrypt files in kernel memory even when the screen is locked, and the encrypted filesystem areas or partition(s) stay accessible. Therefore, an attacker who gains the ability to execute code on a locked device in a sufficiently privileged context can not only backdoor the device, but can also directly access user data.(Caveat: We have not looked into what happens to work profile data when a user who has a work profile toggles off the work profile.)
The bug reports referenced in this blogpost, and the corresponding proof-of-concept code, are available at:https://bugs.chromium.org/p/project-zero/issues/detail?id=1583 ("directory traversal over USB via injection in blkid output")https://bugs.chromium.org/p/project-zero/issues/detail?id=1590 ("privesc zygote->init; chain from USB")
These issues were fixed as CVE-2018-9445 (fixed at patch level 2018-08-01) and CVE-2018-9488 (fixed at patch level 2018-09-01).The attack surfaceMany Android phones support USB host mode (often using OTG adapters). This allows phones to connect to many types of USB devices (this list isn't necessarily complete):
  • USB sticks: When a USB stick is inserted into an Android phone, the user can copy files between the system and the USB stick. Even if the device is locked, Android versions before P will still attempt to mount the USB stick. (Android 9, which was released after these issues were reported, has logic in vold that blocks mounting USB sticks while the device is locked.)
  • USB keyboards and mice: Android supports using external input devices instead of using the touchscreen. This also works on the lockscreen (e.g. for entering the PIN).
  • USB ethernet adapters: When a USB ethernet adapter is connected to an Android phone, the phone will attempt to connect to a wired network, using DHCP to obtain an IP address. This also works if the phone is locked.

This blogpost focuses on USB sticks. Mounting an untrusted USB stick offers nontrivial attack surface in highly privileged system components: The kernel has to talk to the USB mass storage device using a protocol that includes a subset of SCSI, parse its partition table, and interpret partition contents using the kernel's filesystem implementation; userspace code has to identify the filesystem type and instruct the kernel to mount the device to some location. On Android, the userspace implementation for this is mostly in vold (one of the processes that are considered to have kernel-equivalent privileges), which uses separate processes in restrictive SELinux domains to e.g. determine the filesystem types of partitions on USB sticks.
The bug (part 1): Determining partition attributesWhen a USB stick has been inserted and vold has determined the list of partitions on the device, it attempts to identify three attributes of each partition: Label (a user-readable string describing the partition), UUID (a unique identifier that can be used to determine whether the USB stick is one that has been inserted into the device before), and filesystem type. In the modern GPT partitioning scheme, these attributes can mostly be stored in the partition table itself; however, USB sticks tend to use the MBR partition scheme instead, which can not store UUIDs and labels. For normal USB sticks, Android supports both the MBR partition scheme and the GPT partition scheme.
To provide the ability to label partitions and assign UUIDs to them even when the MBR partition scheme is used, filesystems implement a hack: The filesystem header contains fields for these attributes, allowing an implementation that has already determined the filesystem type and knows the filesystem header layout of the specific filesystem to extract this information in a filesystem-specific manner. When vold wants to determine label, UUID and filesystem type, it invokes /system/bin/blkid in the blkid_untrusted SELinux domain, which does exactly this: First, it attempts to identify the filesystem type using magic numbers and (failing that) some heuristics, and then, it extracts the label and UUID. It prints the results to stdout in the following format:
/dev/block/sda1: LABEL="<label>" UUID="<uuid>" TYPE="<type>"
However, the version of blkid used by Android did not escape the label string, and the code responsible for parsing blkid's output only scanned for the first occurrences of UUID=" and TYPE=". Therefore, by creating a partition with a crafted label, it was possible to gain control over the UUID and type strings returned to vold, which would otherwise always be a valid UUID string and one of a fixed set of type strings.The bug (part 2): Mounting the filesystemWhen vold has determined that a newly inserted USB stick with an MBR partition table contains a partition of type vfat that the kernel's vfat filesystem implementation should be able to mount, PublicVolume::doMount() constructs a mount path based on the filesystem UUID, then attempts to ensure that the mountpoint directory exists and has appropriate ownership and mode, and then attempts to mount over that directory:
   if (mFsType != "vfat") {        LOG(ERROR) << getId() << " unsupported filesystem " << mFsType;        return -EIO;    }    if (vfat::Check(mDevPath)) {        LOG(ERROR) << getId() << " failed filesystem check";        return -EIO;    }    // Use UUID as stable name, if available    std::string stableName = getId();    if (!mFsUuid.empty()) {        stableName = mFsUuid;    }    mRawPath = StringPrintf("/mnt/media_rw/%s", stableName.c_str());    [...]    if (fs_prepare_dir(mRawPath.c_str(), 0700, AID_ROOT, AID_ROOT)) {        PLOG(ERROR) << getId() << " failed to create mount points";        return -errno;    }    if (vfat::Mount(mDevPath, mRawPath, false, false, false,            AID_MEDIA_RW, AID_MEDIA_RW, 0007, true)) {        PLOG(ERROR) << getId() << " failed to mount " << mDevPath;        return -EIO;    }
The mount path is determined using a format string, without any sanity checks on the UUID string that was provided by blkid. Therefore, an attacker with control over the UUID string can perform a directory traversal attack and cause the FAT filesystem to be mounted outside of /mnt/media_rw.
This means that if an attacker inserts a USB stick with a FAT filesystem whose label string is 'UUID="../##' into a locked phone, the phone will mount that USB stick to /mnt/##.
However, this straightforward implementation of the attack has several severe limitations; some of them can be overcome, others worked around:
  • Label string length: A FAT filesystem label is limited to 11 bytes. An attacker attempting to perform a straightforward attack needs to use the six bytes 'UUID="' to start the injection, which leaves only five characters for the directory traversal - insufficient to reach any interesting point in the mount hierarchy. The next section describes how to work around that.
  • SELinux restrictions on mountpoints: Even though vold is considered to be kernel-equivalent, a SELinux policy applies some restrictions on what vold can do. Specifically, the mounton permission is restricted to a set of permitted labels.
  • Writability requirement: fs_prepare_dir() fails if the target directory is not mode 0700 and chmod() fails.
  • Restrictions on access to vfat filesystems: When a vfat filesystem is mounted, all of its files are labeled as u:object_r:vfat:s0. Even if the filesystem is mounted in a place from which important code or data is loaded, many SELinux contexts won't be permitted to actually interact with the filesystem - for example, the zygote and system_server aren't allowed to do so. On top of that, processes that don't have sufficient privileges to bypass DAC checks also need to be in the media_rw group. The section "Dealing with SELinux: Triggering the bug twice" describes how these restrictions can be avoided in the context of this specific bug.
Exploitation: Chameleonic USB mass storageAs described in the previous section, a FAT filesystem label is limited to 11 bytes. blkid supports a range of other filesystem types that have significantly longer label strings, but if you used such a filesystem type, you'd then have to make it past the fsck check for vfat filesystems and the filesystem header checks performed by the kernel when mounting a vfat filesystem. The vfat kernel filesystem doesn't require a fixed magic value right at the start of the partition, so this might theoretically work somehow; however, because several of the values in a FAT filesystem header are actually important for the kernel, and at the same time, blkid also performs some sanity checks on superblocks, the PoC takes a different route.
After blkid has read parts of the filesystem and used them to determine the filesystem's type, label and UUID, fsck_msdos and the in-kernel filesystem implementation will re-read the same data, and those repeated reads actually go through to the storage device. The Linux kernel caches block device pages when userspace directly interacts with block devices, but __blkdev_put() removes all cached data associated with a block device when the last open file referencing the device is closed.
A physical attacker can abuse this by attaching a fake storage device that returns different data for multiple reads from the same location. This allows us to present, for example, a romfs header with a long label string to blkid while presenting a perfectly normal vfat filesystem to fsck_msdos and the in-kernel filesystem implementation.
This is relatively simple to implement in practice thanks to Linux' built-in support for device-side USB. Andrzej Pietrasiewicz's talk "Make your own USB gadget" is a useful introduction to this topic. Basically, the kernel ships with implementations for device-side USB mass storage, HID devices, ethernet adapters, and more; using a relatively simple pseudo-filesystem-based configuration interface, you can configure a composite gadget that provides one or multiple of these functions, potentially with multiple instances, to the connected device. The hardware you need is a system that runs Linux and supports device-side USB; for testing this attack, a Raspberry Pi Zero W was used.
The f_mass_storage gadget function is designed to use a normal file as backing storage; to be able to interactively respond to requests from the Android phone, a FUSE filesystem is used as backing storage instead, using the direct_io option / the FOPEN_DIRECT_IO flag to ensure that our own kernel doesn't add unwanted caching.
At this point, it is already possible to implement an attack that can steal, for example, photos stored on external storage. Luckily for an attacker, immediately after a USB stick has been mounted, com.android.externalstorage/.MountReceiver is launched, which is a process whose SELinux domain permits access to USB devices. So after a malicious FAT partition has been mounted over /data (using the label string 'UUID="../../data'), the zygote forks off a child with appropriate SELinux context and group membership to permit accesses to USB devices. This child then loads bytecode from /data/dalvik-cache/, permitting us to take control over com.android.externalstorage, which has the necessary privileges to exfiltrate external storage contents.
However, for an attacker who wants to access not just photos, but things like chat logs or authentication credentials stored on the device, this level of access should normally not be sufficient on its own.Dealing with SELinux: Triggering the bug twiceThe major limiting factor at this point is that, even though it is possible to mount over /data, a lot of the highly-privileged code running on the device is not permitted to access the mounted filesystem. However, one highly-privileged service does have access to it: vold.
vold actually supports two types of USB sticks, PublicVolume and PrivateVolume. Up to this point, this blogpost focused on PublicVolume; from here on, PrivateVolume becomes important.A PrivateVolume is a USB stick that must be formatted using a GUID Partition Table. It must contain a partition that has type UUID kGptAndroidExpand (193D1EA4-B3CA-11E4-B075-10604B889DCF), which contains a dm-crypt-encrypted ext4 (or f2fs) filesystem. The corresponding key is stored at /data/misc/vold/expand_{partGuid}.key, where {partGuid} is the partition GUID from the GPT table as a normalized lowercase hexstring.
As an attacker, it normally shouldn't be possible to mount an ext4 filesystem this way because phones aren't usually set up with any such keys; and even if there is such a key, you'd still have to know what the correct partition GUID is and what the key is. However, we can mount a vfat filesystem over /data/misc and put our own key there, for our own GUID. Then, while the first malicious USB mass storage device is still connected, we can connect a second one that is mounted as PrivateVolume using the keys vold will read from the first USB mass storage device. (Technically, the ordering in the last sentence isn't entirely correct - actually, the exploit provides both mass storage devices as a single composite device at the same time, but stalls the first read from the second mass storage device to create the desired ordering.)
Because PrivateVolume instances use ext4, we can control DAC ownership and permissions on the filesystem; and thanks to the way a PrivateVolume is integrated into the system, we can even control SELinux labels on that filesystem.
In summary, at this point, we can mount a controlled filesystem over /data, with arbitrary file permissions and arbitrary SELinux contexts. Because we control file permissions and SELinux contexts, we can allow any process to access files on our filesystem - including mapping them with PROT_EXEC.Injecting into zygoteThe zygote process is relatively powerful, even though it is not listed as part of the TCB. By design, it runs with UID 0, can arbitrarily change its UID, and can perform dynamic SELinux transitions into the SELinux contexts of system_server and normal apps. In other words, the zygote has access to almost all user data on the device.
When the 64-bit zygote starts up on system boot, it loads code from /data/dalvik-cache/arm64/system@framework@boot*.{art,oat,vdex}. Normally, the oat file (which contains an ELF library that will be loaded with dlopen()) and the vdex file are symlinks to files on the immutable /system partition; only the art file is actually stored on /data. But we can instead make system@framework@boot.art and system@framework@boot.vdex symlinks to /system (to get around some consistency checks without knowing exactly which Android build is running on the device) while placing our own malicious ELF library at system@framework@boot.oat (with the SELinux context that the legitimate oat file would have). Then, by placing a function with __attribute__((constructor)) in our ELF library, we can get code execution in the zygote as soon as it calls dlopen() on startup.
The missing step at this point is that when the attack is performed, the zygote is already running; and this attack only works while the zygote is starting up.Crashing the systemThis part is a bit unpleasant.
When a critical system component (in particular, the zygote or system_server) crashes (which you can simulate on an eng build using kill), Android attempts to automatically recover from the crash by restarting most userspace processes (including the zygote). When this happens, the screen first shows the boot animation for a bit, followed by the lock screen with the "Unlock for all features and data" prompt that normally only shows up after boot. However, the key material for accessing user data is still present at this point, as you can verify if ADB is on by running "ls /sdcard" on the device.
This means that if we can somehow crash system_server, we can then inject code into the zygote during the following userspace restart and will be able to access user data on the device.
Of course, mounting our own filesystem over /data is very crude and makes all sorts of things fail, but surprisingly, the system doesn't immediately fall over - while parts of the UI become unusable, most places have some error handling that prevents the system from failing so clearly that a restart happens.After some experimentation, it turned out that Android's code for tracking bandwidth usage has a safety check: If the network usage tracking code can't write to disk and >=2MiB (mPersistThresholdBytes) of network traffic have been observed since the last successful write, a fatal exception is thrown. This means that if we can create some sort of network connection to the device and then send it >=2MiB worth of ping flood, then trigger a stats writeback by either waiting for a periodic writeback or changing the state of a network interface, the device will reboot.
To create a network connection, there are two options:
  • Connect to a wifi network. Before Android 9, even when the device is locked, it is normally possible to connect to a new wifi network by dragging down from the top of the screen, tapping the drop-down below the wifi symbol, then tapping on the name of an open wifi network. (This doesn't work for networks protected with WPA, but of course an attacker can make their own wifi network an open one.) Many devices will also just autoconnect to networks with certain names.
  • Connect to an ethernet network. Android supports USB ethernet adapters and will automatically connect to ethernet networks.

For testing the exploit, a manually-created connection to a wifi network was used; for a more reliable and user-friendly exploit, you'd probably want to use an ethernet connection.
At this point, we can run arbitrary native code in zygote context and access user data; but we can't yet read out the raw disk encryption key, directly access the underlying block device, or take a RAM dump (although at this point, half the data that would've been in a RAM dump is probably gone anyway thanks to the system crash). If we want to be able to do those things, we'll have to escalate our privileges a bit more.From zygote to voldEven though the zygote is not supposed to be part of the TCB, it has access to the CAP_SYS_ADMIN capability in the initial user namespace, and the SELinux policy permits the use of this capability. The zygote uses this capability for the mount() syscall and for installing a seccomp filter without setting the NO_NEW_PRIVS flag. There are multiple ways to abuse CAP_SYS_ADMIN; in particular, on the Pixel 2, the following ways seem viable:
  • You can install a seccomp filter without NO_NEW_PRIVS, then perform an execve() with a privilege transition (SELinux exec transition, setuid/setgid execution, or execution with permitted file capability set). The seccomp filter can then force specific syscalls to fail with error number 0 - which e.g. in the case of open() means that the process will believe that the syscall succeeded and allocated file descriptor 0. This attack works here, but is a bit messy.
  • You can instruct the kernel to use a file you control as high-priority swap device, then create memory pressure. Once the kernel writes stack or heap pages from a sufficiently privileged process into the swap file, you can edit the swapped-out memory, then let the process load it back. Downsides of this technique are that it is very unpredictable, it involves memory pressure (which could potentially cause the system to kill processes you want to keep, and probably destroys many forensic artifacts in RAM), and requires some way to figure out which swapped-out pages belong to which process and are used for what. This requires the kernel to support swap.
  • You can use pivot_root() to replace the root directory of either the current mount namespace or a newly created mount namespace, bypassing the SELinux checks that would have been performed for mount(). Doing it for a new mount namespace is useful if you only want to affect a child process that elevates its privileges afterwards. This doesn't work if the root filesystem is a rootfs filesystem. This is the technique used here.

In recent Android versions, the mechanism used to create dumps of crashing processes has changed: Instead of asking a privileged daemon to create a dump, processes execute one of the helpers /system/bin/crash_dump64 and /system/bin/crash_dump32, which have the SELinux label u:object_r:crash_dump_exec:s0. Currently, when a file with such a label is executed by any SELinux domain, an automatic domain transition to the crash_dump domain is triggered (which automatically implies setting the AT_SECURE flag in the auxiliary vector, instructing the linker of the new process to be careful with environment variables like LD_PRELOAD):
https://android.googlesource.com/platform/system/sepolicy/+/master/private/domain.te#1:domain_auto_trans(domain, crash_dump_exec, crash_dump);
At the time this bug was reported, the crash_dump domain had the following SELinux policy:
https://android.googlesource.com/platform/system/sepolicy/+/a3b3bdbb2fdbb4c540ef4e6c3ba77f5723ccf46d/public/crash_dump.te:[...]allow crash_dump {  domain  -init  -crash_dump  -keystore  -logd}:process { ptrace signal sigchld sigstop sigkill };[...]r_dir_file(crash_dump, domain)[...]
This policy permitted crash_dump to attach to processes in almost any domain via ptrace() (providing the ability to take over the process if the DAC controls permit it) and allowed it to read properties of any process in procfs. The exclusion list for ptrace access lists a few TCB processes; but notably, vold was not on the list. Therefore, if we can execute crash_dump64 and somehow inject code into it, we can then take over vold.
Note that the ability to actually ptrace() a process is still gated by the normal Linux DAC checks, and crash_dump can't use CAP_SYS_PTRACE or CAP_SETUID. If a normal app managed to inject code into crash_dump64, it still wouldn't be able to leverage that to attack system components because of the UID mismatch.
If you've been reading carefully, you might now wonder whether we could just place our own binary with context u:object_r:crash_dump_exec:s0 on our fake /data filesystem, and then execute that to gain code execution in the crash_dump domain. This doesn't work because vold - very sensibly - hardcodes the MS_NOSUID flag when mounting USB storage devices, which not only degrades the execution of classic setuid/setgid binaries, but also degrades the execution of files with file capabilities and executions that would normally involve automatic SELinux domain transitions (unless the SELinux policy explicitly opts out of this behavior by granting PROCESS2__NOSUID_TRANSITION).
To inject code into crash_dump64, we can create a new mount namespace with unshare() (using our CAP_SYS_ADMIN capability), then call pivot_root() to point the root directory of our process into a directory we fully control, and then execute crash_dump64. Then the kernel parses the ELF headers of crash_dump64, reads the path to the linker (/system/bin/linker64), loads the linker into memory from that path (relative to the process root, so we can supply our own linker here), and executes it.
At this point, we can execute arbitrary code in crash_dump context and escalate into vold from there, compromising the TCB. At this point, Android's security policy considers us to have kernel-equivalent privileges; however, to see what you'd have to do from here to gain code execution in the kernel, this blogpost goes a bit further.From vold to init contextIt doesn't look like there is an easy way to get from vold into the real init process; however, there is a way into the init SELinux context. Looking through the SELinux policy for allowed transitions into init context, we find the following policy:
https://android.googlesource.com/platform/system/sepolicy/+/master/private/kernel.te:domain_auto_trans(kernel, init_exec, init)
This means that if we can get code running in kernel context to execute a file we control labeled init_exec, on a filesystem that wasn't mounted with MS_NOSUID, then our file will be executed in init context.
The only code that is running in kernel context is the kernel, so we have to get the kernel to execute the file for us. Linux has a mechanism called "usermode helpers" that can do this: Under some circumstances, the kernel will delegate actions (such as creating coredumps, loading key material into the kernel, performing DNS lookups, ...) to userspace code. In particular, when a nonexistent key is looked up (e.g. via request_key()), /sbin/request-key (hardcoded, can only be changed to a different static path at kernel build time with CONFIG_STATIC_USERMODEHELPER_PATH) will be invoked.
Being in vold, we can simply mount our own ext4 filesystem over /sbin without MS_NOSUID, then call request_key(), and the kernel invokes our request-key in init context.
The exploit stops at this point; however, the following section describes how you could build on it to gain code execution in the kernel.From init context to the kernelFrom init context, it is possible to transition into modprobe or vendor_modprobe context by executing an appropriately labeled file after explicitly requesting a domain transition (note that this is domain_trans(), which permits a transition on exec, not domain_auto_trans(), which automatically performs a transition on exec):
domain_trans(init, { rootfs toolbox_exec }, modprobe)domain_trans(init, vendor_toolbox_exec, vendor_modprobe)
modprobe and vendor_modprobe have the ability to load kernel modules from appropriately labeled files:
allow modprobe self:capability sys_module;allow modprobe { system_file }:system module_load;allow vendor_modprobe self:capability sys_module;allow vendor_modprobe { vendor_file }:system module_load;
Android nowadays doesn't require signatures for kernel modules:
walleye:/ # zcat /proc/config.gz | grep MODULECONFIG_MODULES_USE_ELF_RELA=yCONFIG_MODULES=y# CONFIG_MODULE_FORCE_LOAD is not setCONFIG_MODULE_UNLOAD=yCONFIG_MODULE_FORCE_UNLOAD=yCONFIG_MODULE_SRCVERSION_ALL=y# CONFIG_MODULE_SIG is not set# CONFIG_MODULE_COMPRESS is not setCONFIG_MODULES_TREE_LOOKUP=yCONFIG_ARM64_MODULE_CMODEL_LARGE=yCONFIG_ARM64_MODULE_PLTS=yCONFIG_RANDOMIZE_MODULE_REGION_FULL=yCONFIG_DEBUG_SET_MODULE_RONX=y
Therefore, you could execute an appropriately labeled file to execute code in modprobe context, then load an appropriately labeled malicious kernel module from there.Lessons learnedNotably, this attack crosses two weakly-enforced security boundaries: The boundary from blkid_untrusted to vold (when vold uses the UUID provided by blkid_untrusted in a pathname without checking that it resembles a valid UUID) and the boundary from the zygote to the TCB (by abusing the zygote's CAP_SYS_ADMIN capability). Software vendors have, very rightly, been stressing for quite some time that it is important for security researchers to be aware of what is, and what isn't, a security boundary - but it is also important for vendors to decide where they want to have security boundaries and then rigorously enforce those boundaries. Unenforced security boundaries can be of limited use - for example, as a development aid while stronger isolation is in development -, but they can also have negative effects by obfuscating how important a component is for the security of the overall system.
In this case, the weakly-enforced security boundary between vold and blkid_untrusted actually contributed to the vulnerability, rather than mitigating it. If the blkid code had run in the vold process, it would not have been necessary to serialize its output, and the injection of a fake UUID would not have worked.
Categories: Security

IBM Power System E980: Technical Overview and Introduction

IBM Redbooks Site - Fri, 09/07/2018 - 09:30
Redpaper, published: Fri, 7 Sep 2018

This IBM® Redpaper™ publication provides a broad understanding of a new architecture of the IBM Power System E980 (9080-M95) server that supports IBM AIX®, IBM i, and Linux operating systems (OSes).

Categories: Technology

In the news

iPhone J.D. - Thu, 09/06/2018 - 23:47

Earlier this year, Apple announced a new iPad with support for the new Logitech Crayon, a stylus this is almost as good as the Apple Pencil for half the price.  Although the Crayon was only available for the education market, I said at the time that I hoped it would give rise to many new stylus options with the precision of the Apple Pencil.  The jury is still out on whether additional styluses are coming, but in a baby step towards that future, attorney John Voorhees of MacStories reports that Apple announced this week that the Logitech Crayon will be available for everyone to purchase, even if you are not in the education sector, starting September 12.  Of course, that is also the day next week when Apple has scheduled a big event at its campus to show off the new iPhones and who knows what else. The Crayon announcement makes me think that we may see a new iPad next week, and if Apple wants to show off even more new stylus options next week, I would certainly love that.  And now, the news of note from the past week:

  • The Lit Software blog features Arizona attorney Brian Snyder and explains how he uses his iPad in his law practice.
  • What will the new iPhones being unveiled next week be called?  John Gruber of Daring Fireball has some theories.
  • Earlier this year, I discussed a service called TeenSafe which restricts the ability of your kids to use your iPhone, but does so at great risk because you have to give the service access to your iCloud backup, which is a problem if the site is hacked — and sure enough, TeenSafe was hacked.  Ben Lovejoy of 9to5Mac reports that a similar product called mSpy accidentally exposed millions of passwords, text messages, contacts, call logs, notes and location data, etc. to the Internet.  I remain very suspicious of services like this.  Be careful out there.
  • Cella Lao Rousseau of iMore discusses some of the best watch stands for the Apple Watch.
  • Recently, a 15-year-old student tried to share with her mother a photo of a mock crime scene from a medical biology class.  She tried to do so using AirDrop, when she was on a plane, and instead she shared the photo with 15 other random passengers, as the plane was taken off.  The chaos that ensued resulted in grounding the Hawaiian Airlines flight for 90 minutes.  Michael Potuck of 9to5Mac has more details (including the picture).  Hopefully something like this will never happen to you.
  • I cannot tell you what features the new iPhones will have next week, but one thing that they surely won't have is support for the upcoming 5G standard.  I see iPhone 5G support in 2019 or 2020.  But that's not that far away, so it isn't too early to think about what 5G means.  I discussed the transition to 5G earlier this year.  This week, David Pogue of Yahoo wrote a good overview of what 5G means, and also created a nice video overview.
  • The Sweet Setup recommends photo editing apps for iOS.
  • Phishing attacks are increasingly common, and are especially dangerous for law firms because of the confidential information stored on law firm networks.  Many law firms have had to deal with major hacking attacks over the last few years.  Yesterday, the Apple Support account on Twitter posted a good, short video explaining how to look out for phishing attacks on your Apple devices:

Got a suspicious email or text? Don't click on any links or open any attachments. It could be a phishing scam.

Watch our video below to see more ways to avoid phishing. pic.twitter.com/YjIHCXbqxH

— Apple Support (@AppleSupport) September 6, 2018

Categories: iPhone Web Sites

Pages

Subscribe to www.hdgonline.net aggregator