Feed aggregator

In the news

iPhone J.D. - Fri, 01/18/2019 - 23:17

This week, Apple and privacy were in the news.  First, Apple CEO Tim Cook wrote an article in Time magazine arguing that individuals have a right to privacy online and promoting legislation to protect privacy.  Although not mentioning them by name, the article seems directed toward companies like Facebook and Google.  (For example, Tony Romm and Elizabeth Dwoskin of the Washington Post reported this week that the Federal Trade Commission is considering a record-setting fine against Facebook for privacy violations.)  Second, the online search engine Duck Duck Go, which has long presented itself as a place that you could go to search for websites while knowing that your privacy is being protected, announced this week that it will use Apple Maps for local searches on the web, as reported by Dieter Bohn of The Verge.  Google Maps has long been the king of online maps, and it is interesting to see Apple Maps being used as an alternative — not to mention seeing Apple Maps being used outside of an iPhone / iPad / Mac.  And now, the rest of the news of note from the past week:

Categories: iPhone Web Sites

Taking a page from the kernel's book: A TLB issue in mremap()

Google Project Zero - Thu, 01/17/2019 - 11:44
Posted by Jann Horn, Project Zero
This is a technical blog post about TLB flushing bugs in kernels, intended for people interested in kernel security and memory management.Introduction: Bugs in Memory Management codeThere have been some pretty scary bugs in memory management in the past, like:
  • CVE-2016-5195, a logic bug in the Linux kernel that permitted writing to shared read-only pages
  • CVE-2018-1038, a Windows bug that existed for about two months, where a bit was set incorrectly in a page table, permitting userspace to overwrite page tables

Memory management is one of the core functions that every kernel and hypervisor needs to implement; and the correctness of memory management code is very important to the security of the entire system. I hope that this post encourages more researchers to look at memory management code and demonstrates that memory management code can have issues with high security impact that fall somewhat outside of the typical security bug patterns.
This blog post focuses on memory management bugs related to TLB flushing. Such bugs can, if the timing works out for the attacker, provide very strong exploitation primitives for local attacks; and they are hard to discover unless you are manually looking for them. They are probably not a big bug class, but occasionally, bugs in TLB flushing logic do happen.
Here are the bugs related to TLB flushing that I have (co-)discovered:
  • Xen PV: XSA-241: "Stale TLB entry due to page type release race" (CVE-2017-15588) (security impact discovered by Xen security team)
  • Linux: insufficient shootdown for paging-structure caches (link)
  • gVisor: pagetable reuse across levels without paging-structure invalidation (link)
  • [XNU: pmap_flush() omits TLB flushes on machines with >32 logical CPU cores (link) - this was already fixed in a binary release when I reported it, so it doesn't really count]
  • Linux: mremap() TLB flush too late with concurrent ftruncate() (link) (CVE-2018-18281)

This blog post focuses on the last bug in the list.
By the way: Note that the gVisor bug is in memory management code written in Go, which is memory-safe-ish. This demonstrates that in operating system code, "logic bugs" in some places, like page table management, can have consequences that are as severe as those of classical memory safety issues, and are not in the scope of the language's safety guarantees. Of course, memory-safe languages are still highly useful because they (should) prevent bugs in random, non-critical pieces of kernel code from corrupting completely unrelated system state, and they allow reviewers to spend more time on the security-critical parts of the system.Introduction: TLBs and paging-structure cachesIf you know what a TLB is, what a TLB flush is, what paging-structure caches are, and how paging-structure caches are managed, you can skip this section. This section does not exhaustively describe the topic of TLB management; in particular, it doesn't deal with processor features like global page table entries and PCID/ASID.
Page tables contain information on how virtual addresses map to physical ones. Page tables are stored in memory, so they are comparatively slow to access; to make address translation fast, CPUs use caches. The classic caches for this are called Translation Lookaside Buffers (TLBs); they cache mappings from virtual to physical page addresses (including mappings for huge pages), or in other words, they (more or less) cache last-level page table entries. (Modern CPU cores often have multiple TLBs with different responsibilities, e.g. Intel CPUs have an instruction TLB, a data TLB and a shared L2 TLB.) TLB parameters are usually fairly well-documented; for example:

Paging-structure caches are usually less well-documented; but there is official documentation about their existence and necessary precautions when dealing with them. Intel calls them "Paging-Structure Caches", Arm calls them "Intermediate table walk caches", AMD documents them as part of the L2 data TLB (at least for 17h processors). Paging-structure caches store copies of non-last-level page table entries; they are used when a virtual address without a corresponding TLB entry is being accessed, and they reduce the number of memory accesses for a page table walk. There are some reverse-engineered details about the paging-structure caches of various processors in a VUSec paper (in Table 1).
It generally has to be assumed that entries in TLBs and paging-structure caches can be evicted by the processor whenever it wants to. Similarly, it has to be assumed that a processor can create entries in TLBs and paging-structure caches from page table entries whenever it wants to, because memory accesses in speculatively executed code can create such entries.
Mechanisms to invalidate TLB entries and paging-structure caches differ between processor architectures:
X86 provides instructions to invalidate either individual TLB entries for the current logical CPU core, or to invalidate the entire TLB (either with or without global entries) for the current logical CPU core. Invalidating the TLB entry for a virtual address also at least implies invalidation of any paging-structure cache entries that could be used for translating that virtual address. The Intel SDM documents this in volume 3A, chapter 4.10.4 ("Invalidation of TLBs and Paging-Structure Caches"). (The SDM says that INVLPG invalidates all paging-structure caches, but doesn't make such broad guarantees for individual-address INVPCID as far as I can tell.) To perform TLB invalidation across logical CPU cores, an operating system has to manually run code that invalidates TLB entries on each logical CPU core; this is normally implemented by sending Inter-Processor Interrupts (via APIC) from the processor that wants to perform a TLB invalidation to all other processors that might have relevant stale TLB or paging-structure cache entries.
The ARM architecture provides magic instructions that can perform cross-core TLB invalidation for you; however, if you also need to synchronize against page table walks implemented in software (like the Linux kernel), you may have to send IPIs anyway (depending on the synchronization mechanism used for page table walks).
The general code pattern for performing cache invalidations for page table entries is:
  1. Remove an entry from a page table, but keep holding a reference to the physical page it points to.
  2. Perform a TLB flush (either for a specific address, or for the entire address space) across all cores that might be using the same page tables as the current thread.
  3. Drop the reference that was held on the physical page, potentially freeing it.

This pattern is the same both when unmapping normal data pages and when removing page tables. It can often be batched for better performance - first remove multiple page table entries, then do one TLB flush across cores, then drop all the page references -, but for the mapping of an individual page (including page tables), this pattern is generally true.
On X86 (but ARM64 is similar), there are two bits in a last-level PTE which the CPU can write into as part of address translation: The Accessed bit specifies whether the CPU has ever used the page table entry for address translation; in other words, if the Accessed bit is unset, the value of the page table entry has not been cached by the TLB since the last time the page table entry was written by software. The Dirty bit specifies whether the CPU has ever used the page table entry for a writing memory access; in other words, if the Dirty bit is unset, no TLB entries that can be used to write to the physical page have been created since the last software write to the PTE.Linux: mremap() TLB flush too lateThe bugOn Linux, memory management data structures of a process are protected by multiple locks; in particular, the read/write semaphore mmap_sem in struct mm_struct is used to protect the VMA (virtual memory area) structures, and page table locks (if the kernel is configured normally, implemented using per-page-table spinlocks for lower-level page tables) are used to protect access to page tables. Accesses to the page tables of a process for syscalls such as mmap()/mremap()/munmap(), as well as syscalls for page fault handling, use both the mmap_sem and page table locks. However, some other types of page table access (e.g. operations on all places across the system where a given file is mapped, like an ftruncate() syscall that shrinks a file and frees pages beyond the new end of the file) don't hold the mmap_sem and only use page table locks.
The mremap() syscall allows userspace to move a VMA and its associated page table entries. This syscall moves page tables via mremap_to() -> move_vma() -> move_page_tables() -> move_ptes(). The  move_ptes() function implemented roughly the following logic for moving entries between two L1 page tables, with only the mmap_sem held initially (locked in exclusive mode):
  1. (Take reverse map locks in some cases if the new VMA has been merged into an adjacent VMA.)
  2. Take page table locks on the old and new page tables.
  3. (Do a TLB flush if the direct reclaim path is in the middle of stealing some pages from the current process.)
  4. For each non-empty entry in the relevant range of the current source page table:
    1. Atomically read the current value of the page table entry and clear it (using ptep_get_and_clear(), which e.g. on X86 boils down to a LOCK XCHG).
    2. If the read page table entry is Dirty, set the local force_flush flag to true.
    3. Write the read page table entry into the page table for the new mapping.
  5. Unlock the new page table.
  6. If the force_flush flag was set, perform a TLB flush on the old page table entries that were accessed in step 4.
  7. Unlock the old page table.
  8. (Drop reverse map locks if they were taken.)
  9. If the force_flush flag wasn't set, signal to the caller move_page_tables() that a TLB flush is required.

Later, after iterating over multiple page tables, move_page_tables() then performs a TLB flush on the old address range if requested.
move_ptes() needs to ensure that, when it releases the old page table's reference, there can be no more stale TLB entries. There is nothing in move_ptes() that explicitly drops a reference, but move_ptes() moves the reference into the new page table entry. While the page table locks on the new page table are held, other tasks running concurrently can't yet remove the new page table entry and drop its reference, so things are still fine after step 4c - the page can't be freed. But after step 5, another task can theoretically race with mremap() and drop the page. This is long before move_page_tables() performs the relevant TLB flush on the old address range (this is the bug I reported), and also slightly before the TLB flush is performed in the force_flush case (I didn't notice that, but the kernel security team did).
On modern kernels, the big race window only works for non-Dirty page table entries - in other words, the big race window can only be used for use-after-free reads, not use-after-free writes. However, before commit 5d1904204c99 (from November 2016, first in v4.9), the special case for Dirty page table entries did not exist, and the big race window was also usable for use-after-free writes.
Almost everyone is using kernel versions >=4.9 nowadays - for example, Debian stable ships a kernel based on 4.9. But there are some exceptions: RHEL still ships 3.10-based kernels, and many Android devices are based on kernels older than 4.9. For example, the kernel branches used by Google's Pixel phones are:
  • Google Pixel: 3.18
  • Google Pixel 2: 4.4
  • Google Pixel 3: 4.9

I decided to write an exploit for Google's Pixel 2.Locks and preemptionThis section, along with the following one, describes some background that will be useful for developing an exploit strategy.
The Linux kernel supports three different models for preemption of kernel code, one of which has to be selected at build time:
  • CONFIG_PREEMPT_NONE ("No Forced Preemption (Server)")
  • CONFIG_PREEMPT_VOLUNTARY ("Voluntary Kernel Preemption (Desktop)")
  • CONFIG_PREEMPT ("Preemptible Kernel (Low-Latency Desktop)")

(More preemption types are coming with the realtime patchset, but that hasn't landed yet.)
The preemption model determines what happens when the kernel wishes to interrupt a task that is currently running kernel code - e.g. because a task with higher priority has become runnable and is waiting to be scheduled.
The Pixel 2 uses a kernel configured with CONFIG_PREEMPT. This means that by default, kernel code can be interrupted at any point during its execution. This even works while a task is holding a mutex, while it is holding a semaphore, or while it is in an RCU read-side critical section (depending on kernel configuration). Only something like a spinlock actually suppresses preemption.
As an attacker, we would like to make the race window between the time move_ptes() drops the page table lock and the time the TLB flush occurs in move_page_tables() as big as possible. Here, it is very useful for us that kernel code is preemptible: Because only the mmap_sem is held across the race window, and the mmap_sem does not inhibit preemption, we can potentially convince the scheduler to kick the task off the CPU core while it is in the middle of the race window, and then keep the task off the CPU for an amount of time on the order of milliseconds.
The kernel allows us to set the affinity of our tasks (the list of CPU cores on which a task is allowed to run), and it also allows us to set various scheduler parameters that control the relative priority of our tasks. This means that we can use affinity masks to pin multiple processes we own together onto a single CPU core, with different priorities - meaning that waking up the higher-priority task implies preemption of the lower-priority one. In this case, by assigning the SCHED_IDLE priority to the task running mremap(), pinning it together with a task that has normal priority and is blocking on a read() from a pipe, and then writing to the other side of that pipe in the right moment, we can preempt the mremap() syscall.
To know the right moment for calling write() on the other end of the pipe, we can abuse procfs. The procfs file /proc/<pid>/status contains various fields about the memory use of a process, including the VmPTE field, which shows the amount of memory consumed by the page tables of a process. By busy-polling the status file and monitoring the VmPTE field, it is possible to detect the page table allocations performed by the mremap() syscall.The page allocatorThe Linux page allocator is based on a buddy allocator, implemented in mm/page_alloc.c. This allocator tracks free pages of different orders; an order-n page is 212+n bytes big and is aligned to a 212+n-byte boundary (assuming that the system is using a native page size of 212 bytes).
Page freelists are not just per-order, but also per-zone, per-migration-type and (on NUMA systems, which isn't relevant for Android phones) per-node.
The zone specifies in which ways a page can be used; pages stay associated with a single zone. The following zones can exist; bold text indicates that the zone actually exists on the Pixel 2:
  • ZONE_DMA: like ZONE_NORMAL, but can also be used for DMA with devices that can only address a small subset of physical memory (used by arm64 before kernel 4.16)
  • ZONE_DMA32: like ZONE_NORMAL, but can also be used for DMA with devices that can only use 32-bit physical addresses (used by arm64 since kernel 4.16)
  • ZONE_NORMAL: can be used for normal kernel memory allocations and as userspace memory; page is mapped in the linear mapping
  • ZONE_HIGHMEM: Can only be used for special types of kernel memory allocations and as userspace memory; page is not mapped in the linear mapping. This doesn't exist on arm64, since virtual memory is large enough to map all physical memory.
  • ZONE_MOVABLE: manually reserved for pages that the kernel can (usually) move to a different physical address when needed (basically, userspace memory); this enables limited memory hotplugging and reduces fragmentation (which can help with the allocation of hugepages); the Pixel 2 doesn't seem to be using this
  • ZONE_DEVICE: something about persistent memory? - arm64 never uses this


The migration type of a page specifies either what kind of allocation the page is currently being used for (if the page is currently in use) or what kind of allocation the page should preferably be used for (if the page is free); the intent is to cluster pages that the kernel can reclaim by moving their contents together, allowing the kernel to later create high-order free pages by moving data out of the way. The following migration types exist:

The first two or three of these are the most relevant ones - the rest are kinda special.
The page allocator also has per-cpu, per-zone, per-migratetype freelists as a performance optimization. These only contain order-0 pages. In kernel versions <4.15, one annoying thing about the per-cpu freelists is that they can be accessed from both sides. Normal freelist accesses push and pop on the same end so that pages coming from the freelist are more likely to be in the CPU cache; but when freeing pages that are expected to be cache-cold, and when allocating pages that have to wait for DMA before they are written to the first time, old kernel versions access the freelist from the other end.
The algorithm for allocating pages via get_page_from_freelist(), before entering the slowpath, works roughly as follows (ignoring things like NUMA and atomic/realtime allocations):
  • For each zone (from the most preferred zone to the least preferred zone); in other words, on the Pixel 2, when allocating non-DMA memory, first for ZONE_NORMAL, then for ZONE_DMA:
    • rmqueue_pcplist(): If we want an order-0 page, attempt to allocate from the per-cpu freelist for the current zone and our preferred migratetype. If this freelist is empty, try to refill it by looking through the per-order freelists for the current zone and our preferred migratetype, starting at order 0, iterating through the freelists with increasing order (standard buddy allocator behavior).
    • Attempt to allocate from the buddy allocator directly, by iterating through the per-order freelists for the current zone and our preferred migratetype with increasing order.
    • If we want a movable page, attempt to allocate from MIGRATE_CMA memory instead.
    • __rmqueue_fallback(): Tries to grab a free block of maximum order from a freelist with a different migration type, then potentially changes that block's migration type to the desired one.

For an attacker attempting to exploit a use-after-free at the page allocator level, this means that getting the kernel to reallocate a movable page for an unmovable allocation, or the other way around, requires creating memory pressure that forces the buddy allocator to go through __rmqueue_fallback() and steal pages from a different migration type.Exploit strategyFor exploiting the TLB invalidation race, we want to quickly reallocate the freed movable page from the page cache. Preferably we'll do this through a per-cpu freelist, so it is probably easier to have it reallocated as a movable page instead of forcing a migratetype change. With this strategy, we can't attack things like normal kernel memory allocations or page tables, but we can attack the page cache and anonymous userspace memory. I chose to poison page cache memory, since I wanted to avoid having other userspace processes in the critical timing path of the attack.
This means that at a high level, to perform the attack, we need to pick a victim file page (in other words, a page-aligned and page-sized area in a file) that we want to corrupt, in a file to which we have read-only access (e.g. a shared library containing executable code). Then, we need to poison the page cache entry for the victim file page by running roughly the following steps in a loop:
  1. Somehow evict the victim file page from the page cache.
  2. Allocate a set of file-backed pages (e.g. by writing to a memfd), and map them as mapping A.
  3. Trigger the mremap/ftruncate race to free the file-backed pages without removing the corresponding TLB entries for mapping A.
  4. Start a read from the victim page, causing the kernel to reallocate one of the freed pages as the page cache entry for the victim page.
  5. Poll the contents of pages in mapping A (through the stale TLB entries) until one of them contains the victim page. If a page fault occurs before that, go back to step 1.
  6. At this point, we have a stale TLB entry translating the old mapping A to the victim page. Therefore, we can now repeatedly overwrite the victim page through mapping A. (In theory, it seems like a single overwrite should be sufficient; but in practice, that doesn't seem to work. I'm not sure whether this is caused by some sort of cache inconsistency (because memory is concurrently written via DMA and by software), or whether I did something else wrong.)


On kernels <4.15, because of the annoying two-sided behavior of the per-cpu freelist, when a new physical page is allocated to store the victim page, it comes from the "cold" end of the per-cpu freelist; so instead of simply pushing a page with a stale TLB entry onto the per-cpu freelist and letting the kernel use it for the victim page, it is necessary to quickly push enough pages with stale TLB entries to force the kernel to move all existing per-cpu freelist entries to the global freelist.Forcing page cache reloadsThis section focuses on the first step of the exploit strategy, evicting the victim page from the page cache.
Public prior research on this topic that I used for my PoC is https://arxiv.org/abs/1710.00551 ("Another Flip in the Wall of Rowhammer Defenses"), which uses page cache eviction as a mechanism to repeatedly move file-backed pages to different physical pages. This paper says in section VIII-B:
A fundamental observation we made is that the replacement algorithm of the Linux page cache prioritizes eviction of nonexecutable pages over executable pages.
In shrink_active_list() and page_check_references() in mm/vmscan.c, you can see that file-backed executable pages indeed get special handling:
static void shrink_active_list(unsigned long nr_to_scan,                   struct lruvec *lruvec,                   struct scan_control *sc,                   enum lru_list lru){[...]    /*     * Identify referenced, file-backed active pages and     * give them one more trip around the active list. So     * that executable code get better chances to stay in     * memory under moderate memory pressure.  Anon pages     * are not likely to be evicted by use-once streaming     * IO, plus JVM can create lots of anon VM_EXEC pages,     * so we ignore them here.     */    if ((vm_flags & VM_EXEC) && page_is_file_cache(page)) {        list_add(&page->lru, &l_active);        continue;    }[...]}[...]static enum page_references page_check_references(struct page *page,                          struct scan_control *sc){[...]    /*     * Activate file-backed executable pages after first usage.     */    if (vm_flags & VM_EXEC)        return PAGEREF_ACTIVATE;
   return PAGEREF_KEEP;[...]}
Therefore, executable file-backed pages are used to create memory pressure to evict the victim page.
For this attack, it is also desirable that the victim page, once evicted, is not reloaded from disk until it is accessed the next time. This is not always the case: The kernel has some readahead logic that, depending on the observed memory access pattern, may read large amounts of data (up to VM_MAX_READAHEAD, which is 128KiB) around a page fault from disk. This is implemented in filemap_fault() by calling into do_async_mmap_readahead() / do_sync_mmap_readahead(). An attacking process can simply opt out of this for its own accesses, but it is also desirable to suppress this behavior for accesses coming from other processes that might be executing code from other pages in the victim file.
For this reason, the PoC first evicts the victim page, then accesses all other pages in the victim file through a mapping with MADV_RANDOM to reduce the probability that accesses to those other pages trigger readahead logic: When a page being accessed is present in RAM, synchronous readahead won't happen; and when the page being accessed with a minor fault (i.e. the page is present in the page cache, but no corresponding page table entry exists yet) is not marked as PG_readahead, asynchronous readahead won't happen either.Picking a victim pageMy exploit targets a victim page in the library /system/lib64/libandroid_runtime.so that contains the function com_android_internal_os_Zygote_nativeForkAndSpecialize(). This function is executed in the context of the zygote process whenever an app process needs to be launched — in other words, it shouldn't run very often on an idle device, meaning that we can evict it and then have time to trigger the bug —, and we can trigger its execution by launching an isolated service, so we can easily cause its execution immediately after successfully triggering the bug. The zygote process has the CAP_SYS_ADMIN capability (and is permitted to use it), and because its job is to fork off children that become app processes and system_server, it has access to the contexts of system_server and every app.
To demonstrate that the code injection into the zygote is working, the injected code reads its own SELinux context and then overwrites the hostname with that string (using sethostname()).Putting it togetherThe exploit is packaged in an app that, when you press the "run" button, first uses the code in eviction.c to flush the victim page in /system/lib64/libandroid_runtime.so from the page cache; afterwards, the code in sched_test.c is used to trigger the mremap bug and overwrite the victim page. If sched_test.c reports that it has successfully located and overwritten the targeted code page, the Java code launches the isolated app TriggerService to trigger execution of com_android_internal_os_Zygote_nativeForkAndSpecialize(); otherwise, the attack is restarted.
sched_test.c executes the following threads:
  • idle_worker(): on core 4, with SCHED_IDLE priority; is moved to core 3 during the attack
  • spinner(): on core 4, with normal priority
  • nicer_spinner(): on core 3, with normal priority
  • read_worker(): on core 5, with normal priority
  • main(): on core 6, with normal priority

The following screenshot shows the running exploit, which has performed a few exploit attempts already, but hasn't managed to visibly trigger the bug yet:

In the next screenshot, the exploit has managed to read data through the stale TLB entry, but still hasn't managed to locate and overwrite the victim page:

In the third screenshot, the exploit has succeeded:
TimelineThis bug was reported to the Linux kernel on 2018-10-12.A fix was committed and made public six days later, on 2018-10-18.Two days after that, on 2018-10-20, new upstream stable kernels were released on the branches 4.9, 4.14 and 4.18.On 2018-10-29, we published the bug report.On 2018-11-10, an upstream backport on the 4.4 branch was released.On 2018-11-14, we published the exploit described in this blogpost.
It took more than two months for the upstream kernel change to make its way to user devices; writing an exploit for this bug took far less time.ConclusionThere isn't really an overarching conclusion here, but some takeaways:
  • Bugs in TLB flushing logic can be exploitable and lead to system compromise from unprivileged userspace.
  • When trying to exploit a use-after-free of a physical page on Linux, keep in mind that the page allocator will try to avoid changing the migration types of pages, so usually movable pages (anonymous userspace memory and page cache) will be reused as movable pages, and unmovable pages (normal kernel memory) will be reused as unmovable pages.
  • Knowing a bit about the scheduler, and in particular preemption, can be very helpful for widening kernel race windows. Linux exposes fairly powerful control over scheduling to unprivileged userspace.
  • Android takes months to ship an upstream kernel security fix to users; it would be nice if that was significantly faster.
Categories: Security

Using NFC stickers with Launch Center Pro

iPhone J.D. - Tue, 01/15/2019 - 00:03

Near-field communication, commonly called NFC, is a communications protocol that allows two devices to communicate when they are very close to each other, within about an inch or so.  You might already use NFC every day in an access card for your office, parking garage, etc.  The iPhone has had NFC support since the iPhone 7, but to use NFC on an iPhone 7, iPhone 8, or iPhone X, you first need to launch an app which is made to work with NFC.  That's not convenient.  The newest iPhones — the iPhone XS, iPhone XS Max, and iPhone XR — can support NFC without first launching any special app.  Your iPhone just needs to have the screen turned on and be unlocked.  The idea is that you can tap your iPhone to an NFC tag (or hold it really close) and you can trigger some action.  You still need to have an app to handle the action, but with the newest iPhones that app does not need to be open.  One such app is Launch Center Pro.

Launch Center Pro is an app that you can use to launch shortcuts.  It has been around for a very long time (I reviewed the app back in 2012) and it has improved over the years.  You might, for example, configure the app so that every time you press a button in the app, the app sends a text to one or more people with a specific message. Launch Center Pro is no longer the best automation app on the iPhone now that we also have the Shortcuts app, but the two apps are not identical, and each can do some things that the other cannot do, or cannot do as well.  One example is that Launch Center Pro can support NFC stickers, but Shortcuts cannot.

Here's how it works.  You buy some NFC stickers in the app.   Then you place the sticker someplace, such as on an item on your desk.  Then you tell Launch Center Pro what to do whenever you tap that NFC sticker.  It's not unlike using the "Hey, Siri" function along with Shortcuts, HomeKit, etc. so that something happens (like turn on the dining room lights) when you tell Siri to do that task.  But with NFC, you don't have to say anything out loud, which can be more appropriate in a location like your office, where you might not want other people to hear you talking to Siri.

You buy the Launch Center Pro NFC stickers in the app.  I bought a set of five clear ones for $5, or you can buy a set of five with the app's logo for $8.  Note that for the clear ones, the sticker portion is clear, but you can still see the silver NFC components.  Each sticker is round and about an inch in diameter.

Currently, the stickers sold in the app don't work if affixed to metal objects, such as the back of a MacBook Pro or an iPad.  The developer suggests that this could change in the future if there are enough requests for it.

Place the sticker in the desired location, and then use the Launch Center Pro app to add the sticker to its list of recognized NFC tags.  Now you can create any shortcut in the Launch Center Pro app — which can include, for example, a command to launch a shortcut that you created in the Shortcuts app — and then tell Launch Center Pro to associate a specific NFC tag with that action.

Now, when you tap your iPhone to the NFC tag, you will see an alert at the top of the screen.  Tap that alert and the Launch Center Pro app will launch and the action will occur.

You can have more than one action associated with a single NFC sticker.  When you do this, tapping the NFC sticker with your iPhone will cause the app to ask you to pick one of the actions from a list.

Part of me wishes that I could skip the step of tapping that alert.  It would be faster if I could just tap the NFC sticker and have the automation action run right away.  But as the Help documentation in Launch Center Pro explains, "for security and usability reasons, iOS requires user interaction in order to complete an action. ... If any app could take actions without user intervention, it would allow shady apps to do things like send your phone to malicious websites, pre-fill messages to paid text messaging accounts, or even use malicious NFC stickers to directly compromise your device and steal your persona data."

It's fun to trigger actions that I configure just using a tap on an NFC sticker.  But is it useful?  The answer to that question depends upon your own creativity, and I'll admit that for now, I haven't yet settled upon anything groundbreaking.  I've got one that sends a text to my wife to let her know that I'm about to leave work so I'll be home soon.  I've got one that sends a silly text to my son, just because he and I were playing with the NFC function and configured it that way.  But I know that I'll come up with more useful NFC actions in the future, and I like the idea of having an additional way to trigger actions.  For some folks, it might be useful to tap an NFC sticker to start a timer, making it easier to track time for your timesheets.  Others might find it useful to have a certain song or playlist start playing when you tap the NFC sticker.  Some folks might put a sticker in a kitchen to launch a grocery app.

Note that while the Launch Center Pro app is very powerful, it is also a little complicated to use, especially at first.  There are great help guides to walk you through it, but you are going to have to put a little time into this app the first time that you use it.  And while the app itself is free, you need to pay $4.95 to unlock the NFC feature, or you can choose one of several other payment options.  (I pay a $9.99 yearly subscription which unlocks all of the features, mainly because I love that this developer has long been figuring out ways to push the envelope on iPhone automation so I want to subscribe to encourage future efforts.) 

If you think that triggering actions using an NFC sticker instead of Siri sounds like it could be useful for you, or even if it just sounds like something you would have playing with, then you should check out Launch Center Pro.

Click here to get Launch Center Pro (free): 

Categories: iPhone Web Sites

IBM Spectrum Scale and IBM StoredIQ: Identifying and securing your business data to support regulatory requirements

IBM Redbooks Site - Fri, 01/11/2019 - 08:30
Redpaper, published: Fri, 11 Jan 2019

Having the appropriate storage for hosting business critical data and the proper analytic software for deep inspection of that data is becoming necessary to get deeper insights into the data so that users can categorize which data qualifies for compliance.

Categories: Technology

In the news

iPhone J.D. - Fri, 01/11/2019 - 02:01

This week, the huge CES conference took place in Las Vegas.  Many electronics companies showed off technology that may be coming out later this year.  Although Apple was not an exhibitor, one of the big themes was the number of TV manufacturers who will release new TVs with greatly improved compatibility with iOS, such as adding support for AirPlay and HomeKit.  Samsung TVs will even have an iTunes app, and attorney Nilay Patel of The Verge discusses some of the questions that this raises.  MacStories provided a good overview of many of the CES announcements, with an initial article by attorney John Voorhees and a second article by Ryan Christoffel.  Also, Kentucky attorney Stephen Embry offers some thoughts on how some of the new technology announced at CES may affect lawyers by providing more evidence.  And now, the news of note from the past week:

  • Joseph Cox of Motherboard wrote a series of articles explaining how cellphone companies are selling the location of mobile phones to unsavory third parties.  The carriers have responded by saying that they are ending this practice.  Hopefully that is true.
  • Drew Coffman of The Sweet Setup believes that the best two apps for taking notes on an iPad are Notability and GoodNotes.  Coffman prefers Notability, which is an excellent app, but I enjoy using GoodNotes.
  • Chance Miller of 9to5Mac reviews HomePass, an app that lets you keep all of your HomeKit setup codes in one place.
  • If you use the Shortcuts app on your iPhone and you use Apple Music, you might be interested in this sophisticated and impressive shortcut by Federico Viticci of MacStories which allows you to see the songs added to your library each year which you listened to the most.
  • Jon Fingas of Engadget reviews the upcoming Mophie Juice Pack access, an iPhone case with a battery for your iPhone which also lets you access the Lightning port.
  • Nick Guy of Wirecutter recommends the best iPad Pro cases.
  • Joe Rossignol of MacRumors interviews Reddit user Cedric M. who used sandpaper, dyes, and paint to make his Apple Pencil look like a real pencil.  Fascinating, but don't try this at home.
  • And finally, this fun video shows off some truly amazing and impressive iPad magic performed by Shinya Uchida:

Categories: iPhone Web Sites

Review: ADIRSports Acrylic Universal Treadmill Bookholder -- watch video on your iPad while you use a treadmill

iPhone J.D. - Sun, 01/06/2019 - 22:33

Starting a new year often means getting more serious about exercise, so its time to remove the hangers and dust from your treadmill and returning to a regular walking or running routine.  Some people like to listen to music on a treadmill.  I usually listen to podcasts.  But another nice way to pass the time on a treadmill is to watch video on a screen.  The iPad is perfect for watching videos, and some treadmills have a built-in ledge for holding an iPad, but many models don't.  Since last month, I've been testing out a simple device that I purchased on Amazon for $22, the ADIRSports Acrylic Universal Treadmill Bookholder.  As you can tell from the title, this device can be used to hold books while you are on a treadmill, but it is also advertised as a way to hold an iPad, and that's how I have been using it.

This product comes in multiple sizes, and I purchased the largest one for my 12.9" iPad Pro — the model advertised as 11" x 11" x 2.5".  In retrospect, I see that I could have also purchased the smaller version with a 9" height because the 2018 version of the 12.9" iPad Pro is 8.5" high when it is in landscape orientation, and I never plan to use my iPad in portrait orientation on my treadmill.  Having said that, I'm perfectly happy with the way that the iPad sits a little bit lower on my treadmill with this larger size, and perhaps the extra surface area adds to stability.  There is also a 3.5" version, but you don't need that for a thin iPad; that version would only make sense if you want to fit a thick book underneath the lip.

The back lip of the device is about 1.75" which turns out to be perfect for fitting over the back of my treadmill.  (I own a PaceMaster ProSelect treadmill, but the PaceMaster company went out of business in 2012.)  If the top surface of your treadmill is thicker, you could certainly flip the device and put your iPad in the 1.75" side and put the 2.5" side over your treadmill.

My main concern about a product like this was sturdiness. First, I don't want the Bookholder to slide off of my treadmill while I am walking or running.  I was especially concerned because the top of my treadmill is actually curved.  However, the plastic of my treadmill and the acrylic of this product do a fine job of staying stable when they make contact with one another, and I haven't seen the Bookholder slide left or right at all.

Second, I don't want my iPad to slip off of the device.  Fortunately, that has not been a problem.  Even when my iPad Pro is not in a case, it stays in place while I walk or run on the treadmill.  There are no lips on the sides, so if I physically push my iPad I can make it slide, but even with the vibrations of my treadmill it does not slide on its own.  Better yet, I have been keeping my iPad in the Apple Smart Folio case for the third generation 12.9" iPad Pro, and the silicone provides incredible friction between the back of my iPad Pro and the acrylic of the Bookholder, making everything very stable.

Because of the size of this product (and the iPad it holds), when you use this product you are covering up much of the front panel of your treadmill.  I don't have trouble temporarily moving my iPad to the side to start and stop a workout, but I don't recommend using this product if you need to press lots of buttons on your treadmill during your workout, especially if your hands get sweaty.  But if you start a program on your treadmill that changes pace automatically, or if you decide to just go a long distance at the same pace, so that there is no need to fiddle with buttons during a workout, then this works great.

And that is how I have been using this product.  Much of the time that I use my treadmill, I like to walk at a fast pace for a long distance.  Thus, I choose my settings on the treadmill, then I start a workout on my Apple Watch, and then I press start on the treadmill and put the Bookholder with my iPad in place and press play on my iPad.  Binge watching TV shows from a service like Netflix or Amazon Prime Video, using my AirPods connected wirelessly to my iPad Pro, is a fantastic way to make the time go by on a treadmill.  Indeed, I often go longer than I might have otherwise just because I want to get to the end of an episode before I stop.

This is a very simple product, but it works well, and it gives me a new way to make the time seem to go by more quickly while I am using my treadmill.  If you like the idea of watching video while you are on your treadmill, I can recommend this product.

Click here to get the ADIRSports Acrylic Universal Treadmill Bookholder from Amazon ($21.95)

Categories: iPhone Web Sites

In the news

iPhone J.D. - Sat, 01/05/2019 - 01:01

Hello, 2019!  Last year was a particularly good year in the world of iOS hardware for attorneys.  The iPad Pro 12.9" is one of my favorite Apple devices in many years, the Apple Watch Series 4 is far better than prior models while at the same time seeming like a preview of better things to come, and Apple followed up on the amazing iPhone X in 2017 with three new models with different sizes and capabilities.  What will 2019 bring us?  One thing that I hope to see is improvements to iOS on the iPad so that the software is just as good as the hardware.  But I'm sure that much more is coming, and I agree with most of Jason Snell's 2009 iOS wishlist.  And now, the recent news of note:

  • In a recent decision from the federal Fifth Circuit, Meador v. Apple, Inc., No. 17-40968 (Dec. 18, 2018) (PDF link), the Fifth Circuit affirmed the dismissal of a lawsuit against Apple arising out of a fatal automobile accident caused by a driver who looked down at her iPhone 5 to read a text message instead of paying attention to the road.  The plaintiffs argued that receipt of a text message triggered an unconscious and automatic neurobiological compulsion to read the text message, and that Apple should have made it impossible to receive a text while driving.  The Fifth Circuit held that, under Texas law, the iPhone 5 was not a substantial factor in the driver's tortious acts.  It is an interesting decision on causation.  Of course, Apple did implement Do Not Disturb While Driving in iOS 11 in 2017.
  • Jason Cross of Macworld recommends some of the best Apple Watch apps.
  • Nick Guy of Wirecutter updated his article on recommended iPhone cases.
  • Zac Hall of 9to5Mac reviews Nanoleaf Light Panels and Canvas, tiles for your wall which light up and can be controlled using HomeKit.
  • If you want a sturdy keyboard for your iPad Pro that basically turns it into a laptop, Jason Snell previews the Brydge 12.9 Pro keyboard for the 12.9" iPad Pro.  I don't use a keyboard with my iPad Pro nearly enough to justify a device like this, but if you often use an external iPad keyboard, this does look like a nice option.
  • If you use the powerful Shortcuts app on your iPad, Matthew Cassinelli of The Sweet Setup notes that you can drag-and-drop items into the Shortcuts app.
  • And finally, David Pogue discusses JOMO — the Joy of Missing Out — in a segment on CBS This Morning, explaining how your iPhone can help you to use your iPhone even less:

Categories: iPhone Web Sites

IBM DS8880 Product Guide (Release 8.51)

IBM Redbooks Site - Wed, 01/02/2019 - 08:30
Redpaper, published: Wed, 2 Jan 2019

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

Categories: Technology

IBM Spectrum Scale and IBM StoredIQ: Identifying and securing your business data to support regulatory requirements

IBM Redbooks Site - Mon, 12/31/2018 - 08:30
Draft Redpaper, last updated: Mon, 31 Dec 2018

The appropriate storage for hosting business-critical data and the proper analytic software for deep inspection of that data is necessary, especially for data that is subject to regulatory compliance..

Categories: Technology

Implementing IBM FlashSystem 900 Model AE3

IBM Redbooks Site - Fri, 12/28/2018 - 08:30
Draft Redbook, last updated: Fri, 28 Dec 2018

Today’s global organizations depend on being able to unlock business insights from massive volumes of data.

Categories: Technology

IBM FlashSystem 900 Model AE3 Product Guide

IBM Redbooks Site - Fri, 12/28/2018 - 08:30
Draft Redpaper, last updated: Fri, 28 Dec 2018

Today’s global organizations depend on the ability to unlock business insights from massive volumes of data.

Categories: Technology

IBM FlashSystem A9000R Product Guide (Version 12.3)

IBM Redbooks Site - Fri, 12/28/2018 - 08:30
Redpaper, published: Fri, 28 Dec 2018

This IBM® Redbooks® Product Guide is an overview of the main characteristics, features, and technology that are used in IBM FlashSystem® A9000R Model 415 and Model 425, with IBM FlashSystem A9000R Software V12.3.

Categories: Technology

IBM FlashSystem A9000 Product Guide (Version 12.3)

IBM Redbooks Site - Fri, 12/28/2018 - 08:30
Redpaper, published: Fri, 28 Dec 2018

This IBM® Redbooks® Product Guide is an overview of the main characteristics, features, and technology that are used in IBM FlashSystem® A9000Model 425, with IBM FlashSystem A9000 Software V12.3.

Categories: Technology

Discount on Lit Software apps (TrialPad, TranscriptPad, DocReviewPad)

iPhone J.D. - Thu, 12/27/2018 - 00:10

Lit Software makes some of the very best apps for any attorney using an iPad:  TrialPad (my review), TranscriptPad (my review), and DocReviewApp (my review). If do not yet own all of these apps, you can buy them before December 31, 2018, in the Ultimate Litigation Bundle and save some money.  The discounted price is $249.99, which is $50 off.  And if you already own some but not all of those apps, you can use the App Store option to complete the bundle at a discounted price.  (Note that Lit Software is not a sponsor of iPhone J.D. this month, but the company has been a sponsor in the past.)

For more details, you’ll want to read this post on the Lit Software blog.  As the company explains in that post, at some point in 2019, Lit Software plans to remove the option to individually purchase its apps and instead offer the Lit Suite, a yearly subscription which will give you access to all of Lit Software’s apps, including the three apps noted above as well as new apps that the company releases.  What will these new apps be?  Here is one guess:  I mentioned last year that at ABA TECHSHOW 2018, Lit Software was showing off a very early preview of an app that the company was working on called TimelinePad.

I personally prefer a subscription model for software that I use all the time because I want to provide constant support and encouragement so that the developer has a financial incentive to add new features.  I currently subscribe to lots of iOS apps such as 1Password, Carrot Weather, Launch Center Pro, Overcast, Microsoft Office, etc.  But if you prefer to own your apps, you can still buy the Lit Software apps and they are still supported, and you might as well buy them over the next few days to save some money.  

Click here for the Ultimate Litigation Package ($249.99): 

Categories: iPhone Web Sites

Implementing the IBM Storwize V5000 Gen2 (including the Storwize V5010, V5020, and V5030) with IBM Spectrum Virtualize V8.2.1

IBM Redbooks Site - Fri, 12/21/2018 - 08:30
Draft Redbook, last updated: Fri, 21 Dec 2018

Organizations of all sizes face the challenge of managing massive volumes of increasingly valuable data.

Categories: Technology

Implementing the IBM Storwize V7000 with IBM Spectrum Virtualize V8.2.1

IBM Redbooks Site - Fri, 12/21/2018 - 08:30
Draft Redbook, last updated: Fri, 21 Dec 2018

Continuing its commitment to developing and delivering industry-leading storage technologies, IBM® introduces the IBM Storwize® V7000 solution powered by IBM Spectrum™ Virtualize.

Categories: Technology

Implementing the IBM System Storage SAN Volume Controller with IBM Spectrum Virtualize V8.2.1

IBM Redbooks Site - Fri, 12/21/2018 - 08:30
Draft Redbook, last updated: Fri, 21 Dec 2018

This IBM® Redbooks publication is a detailed technical guide to the IBM System Storage® SAN Volume Controller, which is powered by IBM Spectrum™ Virtualize V8.2.1 IBM SAN Volume Controller is a virtualization appliance solution that maps virtualized volumes that are visible to hosts and applications to physical volumes on storage devices.

Categories: Technology

In the news

iPhone J.D. - Fri, 12/21/2018 - 01:38

This decision came out in late October but I just heard about it.  In G.A.Q.L v. Florida, No. 4D18-1811 (Fla. Dist. Ct. App. 2018), a Florida trial court had ruled that the police could force a minor involved in a car accident to disclose his iPhone passcode, but the appellate court reversed, finding that this would violate the Fifth Amendment.  It gets more complicated than that so you need to read the opinion to get the full details, but this is a fascinating issue.  I often joke that my iPhone is like my second brain — a place for me to store the information that folks with a better memory might just remember.  I'd rather not waste my brain space remembering passwords, dates, numbers, information about friends and family that can be stored in a contact entry, etc.  I feel that when I offload this data from my brain to my iPhone, I can instead use my brain for more complicated tasks like figuring out creative solutions to problems.  I don't know if there is true scientific merit to that way of thinking about it, but it is one of the reasons that my iPhone is so valuable to me — and also a reason that I wouldn't want anyone else looking around in there without my permission.  And now, the news of note from the past week:

  • California attorney David Sparks discusses the 3.0 update to Launch Center Pro, an app that you can use to launch automated actions.  One of the new features is the ability to support NFC stickers.  Place the sticker (you can purchase five for $5) someplace in your house, office, etc., and when you put your iPhone near the sticker, it causes a notification to appear on your iPhone screen, which you can tap to start a series of actions.  If you want an alternative to using Siri and your voice to trigger actions, NFC stickers might be just what you need.  There are lots of other new features too, including a black mode which looks fantastic on an iPhone X or iPhone XS.
  • Virginia attorney Sharon Nelson of Ride the Lightning discusses the worst passwords of 2018.
  • Attorney Jeremy Horwitz discusses the best and worst Apple moments of 2018 in an article for VentureBeat.
  • Federico Viticci of MacStories posted the 2018 edition of his must-have iOS apps.
  • If you are looking to become a cord-cutter, DirecTV Now is one of a few top optics for streaming TV.  Chance Miller of 9to5Mac reports that the DirecTV Now iOS app was updated to support the new 2018 iPad Pro models, plus it improves cloud DVR support.
  • Zac Hall of 9to5Mac reports that you can now play Apple Music on your Amazon Echo speakers and use Alexa to select and play songs.
  • Ellen Lee of Wirecutter recommends apps for managing your child's phone.
  • You can now buy an iPhone cookie from Eleni's as part of its Travel Essentials Set.
  • And finally, in this short video, Apple shows how you can use your Apple Watch to locate your iPhone.  Hopefully you already know this tip, but if not, it is darn useful and worth knowing:

Categories: iPhone Web Sites

Merry Christmas

iPhone J.D. - Thu, 12/20/2018 - 23:16

From all of us here at iPhone J.D. — that would be me, my iPhone, my iPad, and my Apple Watch — Merry Christmas and Happy Holidays.  I hope that you have the opportunity this holiday season to enjoy some time with your family and friends.  Many of them may be getting new Apple products, which could also mean some additional tech support responsibilities for many of you.

Speaking of sharing your talents with others, if you haven't yet had an opportunity to see Apple's 2018 holiday video called Share Your Gifts, here it is:

Categories: iPhone Web Sites

On VBScript

Google Project Zero - Wed, 12/19/2018 - 13:41
Posted by Ivan Fratric, Google Project Zero
Introduction
Vulnerabilities in the VBScript scripting engine are a well known way to attack Microsoft Windows. In order to reduce this attack surface, in Windows 10 Fall Creators Update, Microsoft disabled VBScript execution in Internet Explorer in the Internet Zone and the Restricted Sites Zone by default. Yet this did not deter attackers from using it - in 2018 alone, there have been at least two instances of 0day attacks using vulnerabilities in VBScript: CVE-2018-8174 and CVE-2018-8373. In both of these cases, the delivery method for the exploit were Microsoft Office files with an embedded object which caused malicious VBScript code to be processed using the Internet Explorer engine. For a more detailed analysis of the techniques used in these exploits please refer to their analysis by the original discoverers here and here.
Because of this dubious popularity of VBScript, multiple security researchers took up the challenge of finding (and reporting) other instances of VBScript vulnerabilities, including a number of variants of those vulnerabilities used in the wild. Notably, researchers working with the Zero day initiative discovered multiple instances of vulnerabilities relying on VBScript Class_Terminate callback and Yuki Chen of Qihoo 360 Vulcan Team discovered multiple variants of CVE-2018-8174 (one of the exploits used in the wild).
As a follow up to those events, this blog post tries to answer the following question: Despite all of the existing efforts from Microsoft and the security community, how easy is it to still discover new VBScript vulnerabilities? And how strong are Windows policies intended to stop these vulnerabilities from being exploited?
Even more VBScript vulnerabilities
The approach we used to find VBScript vulnerabilities was quite straightforward: We used the already published Domato grammar fuzzing engine and wrote a grammar that describes the built-in VBScript functions, various callbacks and other common patterns. This is the same approach we used successfully previously to find multiple vulnerabilities in the JScript scripting engine and it was relatively straightforward to do the same for VBScript. The grammar and the generator script can be found here.
This approach resulted in uncovering three new VBScript vulnerabilities that we reported to Microsoft and are now fixed. The vulnerabilities are interesting, not because they are complex, but precisely for the opposite reason: they are pretty straightforward (yet, somehow, still survived to this day). Additionally, in several cases, there are parallels that can be drawn between the vulnerabilities used in the wild and the ones we found.
To demonstrate this, before taking a look at the first vulnerability the fuzzer found, let’s take a look at a PoC for the latest VBScript 0day found in the wild:
Class MyClass  Dim array    Private Sub Class_Initialize    ReDim array(2)  End Sub
 Public Default Property Get P    ReDim preserve array(1)  End PropertyEnd Class
Set cls = new MyClasscls.array(2) = cls
Trend Micro has a more detailed analysis, but in short, the most interesting line is
cls.array(2) = cls
In it, the left side is evaluated first and the address of variable at cls.array(2) is computed. Then, the right side is evaluated, and because cls is an object of type MyClass which has a default property getter, it triggers a callback. Inside the callback, the array is resized and the address of the variable computed previously is no longer valid - it now points to the freed memory. This results in writing to a freed memory when the line above gets executed.
Now, let’s compare this sample to the PoC for the first issue we found:
Class MyClass  Private Sub Class_Terminate()    dict.RemoveAll  End SubEnd Class
Set dict = CreateObject("Scripting.Dictionary")Set dict.Item("foo") = new MyClassdict.Item("foo") = 1
On the first glance, this might not appear all that similar, but in reality they are. The line that triggers the issue is
dict.Item("foo") = 1
In it, once again, the left side is allocated first and the address of dict.Item("foo") is computed. Then, a value is assigned to it, but because there is already a value there it needs to be cleared first. Since the existing value is of the type MyClass, this results in a Class_Terminate() callback, in which the dict is cleared. This, once again, causes that the address computed when evaluating the left side of the expression now points to a freed memory.
In both of these cases, the pattern is:
  1. Compute the address of a member variable of some container object
  2. Assign a value to it
  3. Assignment causes a callback in which the container storage is freed
  4. Assignment causes writing to a freed memory

The two differences between these two samples are that:
  1. In the first case, the container used was an array and in the second it was a dictionary
  2. In the first case, the callback used was a default property getter, and in the second case, the callback was Class_Terminate.

Perhaps it was because this similarity with a publicly known sample that this variant was also independently discovered by a researcher working with Trend Micro's Zero Day Initiative and Yuki Chen of Qihoo 360 Vulcan Team. Given this similarity, it would not be surprising if the author of the 0day that was used in the wild also knew about this variant.
The second bug we found wasn’t directly related to any 0days found in the wild (that we know about), however it is a classic example of a scripting engine vulnerability:
Class class1  Public Default Property Get x    ReDim arr(1)  End PropertyEnd Class
set c = new class1arr = Array("b", "b", "a", "a", c)Call Filter(arr, "a")
In it, a Filter function gets called on an array. The Filter function walks the array and returns another array containing just the elements that match the specified substring ("a" in this case). Because one of the members of the input array is an object with a default property getter, this causes a callback, and in the callback the input array is resized. This results in reading variables out-of-bounds once we return from the callback into the implementation of the Filter function.
A possible reason why this bug survived this long could be that the implementation of the Filter function tried to prevent bugs like this by checking if the array size is larger (or equal) than the number of matching objects at every iteration of the algorithm. However, this check fails to account for array members that do not match the given substring (such as elements with the value of "b" in the PoC).
In their advisory, Microsoft (initially) incorrectly classified the impact of this issue as an infoleak. While the bug results in an out-of-bounds read, what is read out-of-bounds (and subsequently returned to the user) is a VBScript variable. If an attacker-controlled data is interpreted as a VBScript variable, this can result in a lot more than just infoleak and can easily be converted into a code execution. This issue is a good example of why, in general, an out-of-bounds read can be more than an infoleak: it always depends on precisely what kind of data is being read and how it is used.
The third bug we found is interesting because it is in the code that was already heavily worked on in order to address CVE-2018-8174 and the variants found by the Qihoo 360 Vulcan Team. In fact, it is possible that the bug we found was introduced when fixing one of the previous issues.
We initially became aware of the problem when the fuzzer generated a sample that resulted in a NULL-pointer dereference with the following (minimized) PoC:
Dim a, r
Class class1End Class
Class class2  Private Sub Class_Terminate()    set a = New class1  End SubEnd Class
a = Array(0)set a(0) = new class2Erase aset r = New RegExpx = r.Replace("a", a)
Why does this result in a NULL-pointer dereference? This is what happens:
  1. An array a is created. At this point, the type of a is an array.
  2. An object of type class2 is set as the only member of the array
  3. The array a is deleted using the Erase function. This also clears all array elements.
  4. Since class2 defines a custom destructor, it gets called during Erase function call.
  5. In the callback, we change the value of a to an object of type class1.The type of a is now an object.
  6. Before Erase returns, it sets the value of variable a to NULL. Now, a is a variable with the type object and the value NULL.
  7. In some cases, when a gets used, this leads to a NULL-pointer dereference.

But, can this scenario be used for more than a NULL-pointer dereference. To answer this question, let’s look at step 5. In it, the value of a is set to an object of type class1. This assignment necessarily increases the reference count of a class1 object. However, later, the value of a is going to be set to NULL without decrementing the reference count. When the PoC above finishes executing, there will be an object of type class1 somewhere in memory with a reference count of 1, but no variable will actually point to it. This leads us to a reference leak scenario. For example, consider the following PoC:
Dim a, c, i
Class class1End Class
Class class2  Private Sub Class_Terminate()    set a = c  End SubEnd Class
Set c = New class1For i = 1 To 1000  a = Array(0)  set a(0) = new class2  Erase aNext
Using the principle described above, the PoC above will increase the reference count for variable c to 1000 when in reality only one object (variable c) will hold a reference to it. Since a reference count in VBScript is a 32-bit integer, if we increase it sufficient amount of times, it is going to overflow and the object might get freed when there are still references to it.
The above is not exactly true, because custom classes in VBScript have protection against reference count overflows, however this is not the case for built-in classes, such as RegExp. So, we can just use an object of type RegExp instead of class1 and the reference count will overflow eventually. As every reference count increase requires a callback, “eventually” here could mean several hours, so the only realistic exploitation scenario would be someone opening a tab/window and forgetting to close it - not really an APT-style attack (unlike the previous bugs discussed) but still a good example how the design of VBScript makes it very difficult to fix the object lifetyme issues.
Hunting for reference leaks
In an attempt to find more reference leaks issues, a simple modification was made to the fuzzer: A counter was added and, every time a custom object was created, in the class constructor, this counter was increased. Similarly, every time an object was deleted, this counter was decreased in the class destructor. When a sample finishes executing and all variables are clear, if this counter is larger than 0, this means there was a reference leak somewhere.
This approach immediately resulted in a variant to the previously described reference leak, which is almost identical but uses ReDim instead of Erase. Microsoft responded that they are considering this a duplicate of the Erase issue.
Unfortunately there is a problem with this approach that prevents it from discovering more interesting reference leak issues: The approach can’t distinguish between “pure” reference leak issues and reference leak issues that are also memory leak issues and thus don’t necessarily have the same security impact. One example of issues this approach gets stuck on are circular references (imagine that object A has a reference to object B and object B also has reference to object A). However, we still believe that finding reference leaks can be automated as described later in this blog post.
Bypassing VBScript execution policy
As mentioned in the introduction, in Windows 10 Fall Creators Update, Microsoft disabled VBScript execution in Internet Explorer in the Internet Zone and the Restricted Sites Zone by default. This is certainly a step in the right direction. However, let’s also examine the weaknesses in this approach and its implementation.
Firstly, note that, by default, this policy only applies to the Internet Zone and the Restricted Sites Zone. If a script runs (or an attacker can make it run) in the Local Intranet Zone or the Trusted Sites Zone, the policy simply does not apply. Presumably this is to strike a balance between the security for the home users and business users that still rely on VBScript on their local intranet. However, it is somewhat debatable whether leaving potential gaps in the end-user security vs. having (behind-the-times) businesses that still rely on VBScript change a default setting strikes the right balance. In the future, we would prefer to see VBScript completely disabled by default in the Internet Explorer engine.
Secondly, when implementing this policy, Microsoft forgot to account for some places where VBScript code can be executed in Internet Explorer. Specifically, Internet Explorer supports MSXML object that has the ability to run VBScript code in XSL Transformations, for example like in the code below.
<?xml version='1.0'?><xsl:stylesheet version="1.0"      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"      xmlns:msxsl="urn:schemas-microsoft-com:xslt"      xmlns:user="http://mycompany.com/mynamespace">
<msxsl:script language="vbscript" implements-prefix="user"> Function xml(str)           a = Array("Hello", "from", "VBscript")           xml = Join(a) End Function</msxsl:script>
<xsl:template match="/">   <xsl:value-of select="user:xml(.)"/></xsl:template>
</xsl:stylesheet>
Microsoft did not disable VBScript execution for MSXML, even for websites running in the Internet Zone. This issue was reported to Microsoft and fixed at the time of publishing this blog post. Interestingly, this is not the first time dangerous functionality was forgotten in MSXML, for example, there was also a fairly straightforward RCE bug earlier this year.
You might think that all of these issues are avoidable if Internet Explorer isn’t used for web browsing, but unfortunately the problem with VBScript (and IE in general) runs deeper than that. Most Windows applications that render web content do it using the Internet Explorer engine, as is the case with Microsoft Office that was used in the recent 0days. It should be said that, earlier this year, Microsoft disabled VBScript creation in Microsoft Office (at least the most recent version), so this popular vector has been blocked. However, there are other applications, including those from third parties, that also use IE engine for rendering web content.
Future research ideas
During this research, some ideas came up that we didn’t get around to implement. Rather than sitting on them, we’ll list them here in case a reader looking for a light research project wants to pick one of them up:
  • Combine VBScript fuzzer with the JScript fuzzer in a way that allows VBScript to access JScript objects/functions and vice-versa. Perhaps issues can be found in the interaction of these two engines. Possibly callbacks from one engine (e.g. default property getter from VBScript) can be triggered in unexpected places in the other engine.

  • Create a better tool for finding reference leaks. This could be accomplished by running IE in the debugger and setting breakpoints on object creation/deletion to track addresses of live objects. Afterwards, memory could be scanned similarly to how it was done here to find if there are any objects alive (with reference count >0) that are not actually referenced from anywhere else in the memory (note: Page Heap should be used to ensure there are no stale references from freed memory).

  • Other objects. During the previous year, a number of bugs were found that rely on Scripting.Dictionary object. Scripting.Dictionary is not one of the built-in VBScript objects, but rather needs to be instantiated using CreateObject function. Are there any other objects available from VBScript that would be interesting to fuzz?

Conclusion
VBScript is a scripting engine from a time when a lot of today’s security considerations weren’t in the forefront of anyone’s thoughts. Because of this, it shouldn’t be surprising that it is a crowd favorite when it comes to attacking Windows systems. And although it received a lot of attention from the security community recently, new vulnerabilities are still straightforward to find.
Microsoft made some good steps in attack surface reduction recently. However in combination with an execution policy bypasses and various applications relying on Internet Explorer engine to render web content, these bugs could still endanger even users using best practices on up-to-date systems. We hope that, in the future, Microsoft is going to take further steps to more comprehensively remove VBScript from all security-relevant contexts.
Categories: Security

Pages

Subscribe to www.hdgonline.net aggregator