Mind the Gap - Uncovering the Android patch gap through binary-only patch analysis HITB conference, April 13, 2018

Mind the Gap - Uncovering the Android patch gap through binary-only patch analysis HITB conference, April 13, 2018
Mind the Gap –
                      Uncovering the Android patch gap through binary-only patch analysis
                                                          HITB conference, April 13, 2018

                                                                 Jakob Lell 
                                                               Karsten Nohl 

SRLabs Template v12
Mind the Gap - Uncovering the Android patch gap through binary-only patch analysis HITB conference, April 13, 2018
Allow us to take you on two intertwined journeys

                                   This talk in a nutshell

                                   § Wanted to understand how fully-maintained Android phones
                                     can be exploited
                                   § Found surprisingly large patch gaps for many Android vendors
                                   § Also found Android exploitation to be unexpectedly difficult

                                   § Wanted to check thousands of firmwares for the presence of
as Logo Horizontal                   hundreds of patches
Pos / Neg
                                   § Developed and scaled a rather unique analysis method
                                   § Created an app for your own analysis

Mind the Gap - Uncovering the Android patch gap through binary-only patch analysis HITB conference, April 13, 2018
Android patching is a known-hard problem

                           Patching challenges                                  Patch ecosystems

                           § Computer OS vendors regularly issue patches         OS vendor
                           § Users “only” have to confirm the installation of    § Microsoft                      OS patches
        Patching is hard     these patches
                                                                                 § Apple                                                   Endpoints & severs
        to start with      § Still, enterprises consider regular patching
                                                                                 § Linux distro
                             among the most effortful security tasks

                           § “The mobile ecosystem’s diversity […]               OS                Chipset        Phone                             Android
                             contributes to security update complexity and       vendor            vendor         vendor                            phones
                             inconsistency.” – FTC report, March 2018 [1]                                                          Telco
          The nature of
          Android makes    § Patches are handed down a long chain of
as Logo Horizontal
Pos / Neg patching so        typically four parties before reaching the user
          much more        § Only some devices get patched (2016: 17% [2]).
          difficult          We focus our research on these “fully patched”

                                                                                 Our research question – How many patching mistakes are made in this complex
                                                                                 Android ecosystem? That is: how many patches go missing?

Vendor patch claims can be unreliable; independent verification is needed

                     How do we determine whether an Android binary has a patch installed, without access to the
                                                  corresponding source code?

                                                            Try exploiting the             Apply binary-only patch
                         Trust vendor claims?
                                                       corresponding vulnerability?               heuristics

                                                      § No exploits publicly            § Find evidence in the binary
                                                        available for most Android        itself on whether a patch is
                                                        bugs                              installed
                                                      § A missing patch also does       § Scale to cover hundreds of
                                                        not automatically imply an        patches and thousands of
                                                        open vulnerability                phones
as Logo Horizontal
                                                        (It’s complicated.
Pos / Neg
                                                        Let’s talk about it later)      § The topic of this

                     Important distinction: A missing patch is not automatically an open security vulnerability.
                     We’ll discuss this a bit later.

Patching is necessary in the Android OS and the underlying Linux kernel

                          Android OS patching (“userland”)                         Linux kernel patching

         Responsibility   § Android Open Source Project (AOSP) is maintained by    § Same kernel that is used for much of the Internet
                            Google                                                 § Maintained by a large ecosystem
                          § In addition, chipset and phone vendors extend the OS   § Chipset and phone vendors contribute hardware
                            to their needs                                           drivers, which are sometimes kept closed-source

         Security         § Most exposed attack surface: The OS is the primary     § Attackable mostly from within device
         relevance          layer of defense for remote exploitation               § Relevant primarily for privilege escalation (“rooting”)

Pos / Neg Patch
as Logo Horizontal
                          § Monthly security bulletins published by Google         § Large number of vulnerability reports, only some of
         situation        § Clear versioning around Android, including a patch       which are relevant for Android
                            level date, which Google certifies                     § Tendency to use old kernels even with latest Android
                            for some phones                                          version; e.g., Kernel 3.18 from 2014, end-of-life: 2017

                          We focus our attention on userland patches


                     § Research motivation

                     § Spot the Android patch gap

                     § Try to exploit Android phones

as Logo Horizontal
Pos / Neg

We want to check hundreds of patches on thousands of Android devices

         Android     Android’s 2017     Source code is    Of these            So far, we       The heuristics would
         userland    security           available for     userland bugs,      implemented      optimally work on
         patch       bulletins list                                           heuristics for   hundreds of thousands
         analysis                                                                              of Android firmwares:
                           ~280              ~240              ~180                 164        – 60,000 Android
                                                                                                 variants [3]
                     bugs (~CVEs)       of these bugs     originate from      of the
                     with Critical or                     C/C++ code          corresponding    – Regular updates for
                     High severity                        (plus a few Java)   patches            many of these variants

as Logo Horizontal   ~700 kernel and    The remaining     We do not yet
Pos / Neg
         scope       medium/low         bugs are in       support most
         (for now)   severity           closed-source     Java patches
                     userland           vendor-specific
                     patches            components

The patch gap: Android patching completeness varies widely for different phones
                                                                               Not affected
                                                                               Patch found applied as claimed
                                                                               Patched found above claimed level       Not tested
                                                                               Patch not found within claimed level    Claimed patch level
                                                                               Patch not found outside claimed level   Android version release date

                                 2016                               2017                                                          Patches ”missing”
                             9   10 11 12   1   2   3   4   5   6          7            8           9        10 11     12        Critical         High

     Google Pixel 2
     Android version 8.1                                                                                                            0                 0
     Patch level: Feb 2018

     Samsung J5 (2016)
     Android version 7.1.1                                                                                                          0                 0
     Patch level: Aug 2017

as Logo Horizontal
      Samsung J3 (2016)
Pos / Neg
     Android version 5.1.1                                                                                                          2                 10
     Patch level: Jan 2018

     Wiko Freddy
     Android version 6.0.1                                                                                                         18                 62
     Patch level: Sep 2017

Binary-only analysis: Conceptually simple

                1 Prepare patch test set                                                2 Test for patch presence

                     Vulnerable source code     patch       Patched source code

                      Compile with different compliers, compiler configurations,
                                                                                                  Binary file
                                             CPU options

                                                                                                 Mask volatile
                           Mask volatile information (e.g. call destinations)
as Logo Horizontal
Pos / Neg

                                                                                            Compare to collections:
                     Collection of unpatched
                                                            Collection of patched
                                                                   binaries         ?       Find match with patched
                                                                                              or unpatched sample

A bit more background: Android firmwares go from source code to binaries in two steps

     Compilercode                            Compiler                               Linker
     contains placeholders that are filled   preprocesses and compiles source       combines the object files into an
     in during preprocessing                 code into object files that are then   executable firmware binary.
                                             fed into the linker
        #include                   stp       x28, x27, [sp,#-32]!         stp      x28, x27, [sp,#-32]!
        #include                   […]                                    […]
        void foo(char* fn){                  orr       w2, wzr, #0x1000             orr      w2, wzr, #0x1000
           char buf[PATH_MAX];               mov       x1, x8                       mov      x1, x8
           strncpy(buf, fn, PATH_MAX);       bl        0                   bl       11b3e8 
as Logo Horizontal
Pos / Neg
                                             […]                                    […]
                                             ret                                    ret

The basic idea: Signatures can be generated from reference source code

                     Compile reference source code (before and after patch)

                     Parse             Disassembly of object file, after compiler but before linker
                     disassembly       0000000000000000 :
                                           0: a9bd7bfd   stp    x29, x30, [sp, #-48]!
                     listing for           4: 910003fd   mov    x29, sp
                     relocation        […]
                                         20: f9413e60    ldr    x0, [x19, #632]
                     entries             24: 52800042    mov    w2, #0x2                         // #2
                                         28: b9402021    ldr    w1, [x1, #32]
       Prepare                           2c: 94000000    bl     0    2c: R_AARCH64_CALL26   impeg2_buf_mgr_release
       patch                           […]
       test set
                     Sanitize instructions              Instruction format of the bl instruction
as Logo Horizontal   Toss out irrelevant destination    100x 01 ii iiii iiii iiii iiii iiii iiii
                     addresses of the instruction
Pos / Neg

                     Create hash of remaining binary code

                     Generate signature containing function length, position/type of relocation entries, and hash of the code

At scale, three compounding challenges need to be solved

                        Too much source code
                        § There is too much source code to collect
                        § Once collected, there is too much source code to compile

                        Too many compilation possibilities
                        § Hard to guess which compiler options to use
                        § Need to compile same source many times

as Logo Horizontal
Pos / Neg
                        Hard to find code “needles” in binary “haystacks”
                        § Without symbol table, whole binary needs to be scanned
                        § Thousands of signatures of arbitrary length

Amount of source code
   Signature generation would require huge amounts of source code                                            Compilation possibilities

                                                                                                             Needles in haystacks

              One Android source code tree is roughly 50 GiB in size
              Source code trees are managed in a manifest, which lists git repositories with revision and path in a
              source code tree
                 +~500 MORE REPOSITORIES

              Signature generation requires many source code trees
              § Hundreds of different Android revisions
as Logo Horizontal
Pos / Neg
                                                             Currently ~1100 source code trees are used in total
                (e.g. android-7.1.2_r33)                     (many more exist!)
              § Device-specific source code trees
                (From Qualcomm Codeaurora CAF)               1100 x 50 GiB = 55 TiB
                                                             Would require huge amount of storage, CPU time, and
                                                             network traffic to check out everything

Amount of source code
   We leverage a FUSE (filesystem in userspace) to retrieve files only on demand                                            Compilation possibilities

                                                                                                                            Needles in haystacks

                     Insight: The same git repositories are used for many manifests.

                         Manifest 1                                                        platform/frameworks/av
                         platform/frameworks/av rev 330d132d                               rev 330d132d
                         platform/frameworks/base rev 85838fea                             rev d43a8fe2
                                                                                           rev deadbeef

                         Manifest 2                                                        platform/frameworks/base
                         platform/frameworks/av rev d43a8fe2                               rev 85838fea
                         platform/frameworks/base rev 18fac24b                             rev 18fac24b
                                                                                           rev cafebabe
                         Manifest 3
                         platform/frameworks/av rev deadbeef
                         platform/frameworks/base rev cafebabe
as Logo Horizontal
Pos / Neg            How this can be leveraged
                     Filesystem in userspace (FUSE)                         Reduces storage requirement by >99%:
                     § Store each git repository only once                  55 TiB => 300 GiB
                         (with git clone --no-checkout)                     Saves network bandwidth and time required for
                     § Extract files from git repository on demand          checkout
                         when the file is read                              Prevents IP blocking by repository servers
                     § Use database for caching directory contents

Amount of source code
   Using our custom FUSE, we can finally generate a large collection of signatures                                        Compilation possibilities

                                                                                                                          Needles in haystacks

                     Mount source code tree          Run source-code analysis        Generate build log
                     § Read manifest                 § Source-code patch analysis    § Run build system in dry-run
                     § Use FUSE filesystem to read     is much easier than binary      mode, don’t compile
                       files on demand                 analysis                        everything
                                                     § Determines whether a          § Save log of all commands to
                                                       signature match means that      be executed
                                                       the patch is applied or not   § Various hacks/fixes to build   Next
                                                                                       system required                question:
          Prepare                                                                                                     How many
          patch                                                                                                       different
          test set   Preprocess source files         Recompile with variants         Generate signatures              compiler
                     § Use command line from         § >50 different compiler        § Evaluate relocation entries    variants do
as Logo Horizontal
Pos / Neg
                       saved build log                 binaries                        and create signatures for      we need?
                     § Save preprocessor output      § All supported CPU types         each compiler variant
                       in database                   § Optimization levels
                                                       (e.g. -O2, -O3)
                                                     § 3897 combinations in total,
                                                       74 in our current optimized

Amount of source code
  Brute-forcing 1000s of compiler variants finds 74 that produce valid signatures                                                               Compilation possibilities

  for all firmwares tested to date                                                                                                              Needles in haystacks

     Tests are regularly optimized
                                                 Successful sub-tests
     §    Our collection includes
          3897 compiler              10000
          configuration variants,
          only 74 of which are       9000
          required for firmwares
                                     8000                                                                     §   For 224 tested 64-bit firmwares,
          tested to date.
                                                                                                                  signatures from the first 74
      § To ensure a high rate of     7000
          conclusive tests, test                                                                                  compiler config variants provide
                                                                                                                  full test coverage
          results are regularly      6000
                                                                                                              §   74 variants à
          checked for success.
      § The test suite is amended    5000                                                                         6,944 signatures à 3MB
                                                 Just two variants account for 60% of successful sub-tests:   §   We tried 3,897 variants à
          with additional variants
                                     4000        - gcc version 4.9.x-google 20140827 (prerelease)                 775,795 signatures à 34MB
          from the collection as
                                                 - Android clang version 3.8.256229
as Logo Horizontal
Pos / Neg                            3000        Both were run with each git’s default configuration
      § The collection itself is
          amended with additional    2000
          compiler configuration
          variants as they become    1000
                                             0     10      20      30     40     50      60     70     80      90    100 110              120        130
                                                                     # compiler config variants = compilers x [compiler options]

Amount of source code
   Finding needles in a haystack: What do we do if there is no symbol table?                                                   Compilation possibilities

                                                                                                                               Needles in haystacks

                     Function   Simply compare function with pre-computed samples
                     found in

                     Function   Challenge                             Insight                           Solution
                     not in
                                Checking signature at each position   Similar problem already           Take advantage of rsync rolling
     Test for        symbol
                                is computationally expensive          solved by rsync                   checksum algorithm
     patch           table

as Logo Horizontal
                                Relocation entries are not known      Relocation entries are only       Guess potential relocation entries
Pos / Neg                       while calculating checksum            used for certain instructions     based on instruction type and
                                                                                                        sanitize args before checksumming

                                32bit code uses Thumb encoding,       Same binary code is often         Only test 64bit code
                                for which instruction start is not    also available in 64bit version
                                always clear                          based on same source code

Amount of source code
  Using improved rolling signatures, we can efficiently search the binary ‘haystack’                                                               Compilation possibilities

  for our code ‘needles’                                                                                                                           Needles in haystacks

                                     Process step                         Hex dump of instruction     Assembly code / instructions
       Sanitize arguments before     Potential relocation entries are
                                     detected based on instruction.       97fee7a2                   bl            c7c40 
                                     Zero-out volatile bits               94000000                   bl            0
                                                                          f10002ff                   cmp           x23, #0x0
                                                                          1a9f17e8                   cset          w8, eq
        Match signatures of          Size-8 window matches on             b40000b6                   cbz           x22, 10ddbc
        arbitrary lengths using      start of signature                   3707fdc8                   tbnz          w8, #0, 10dd6
        sliding windows                                                   f10006d6                   subs          x22, x22, #0x1
        § Two overlapping
             sliding windows                                              54ffff42                   b.cs          10dd9c
        § Only needs powers of                                            35fffd48                   cbnz          w8, 10dd64
             2 as window sizes to
as Logo Horizontal
                                                                          36000255                   tbz           w21, #0, 10de08
Pos / Neg
             match arbitrary
                                     Overlapping window matches
                                                                          394082e8                   ldrb          w8, [x23,#32]
             function lengths
        § Allows efficient           on end of signature                  35000208                   cbnz          w8, 10de08
             scanning of a binary                                         52adad21                   mov           w1, #0x6d690000
             for a large number of                                        320003e8                   orr           w8, wzr, #0x1
                                                                          728daca1                   movk          w1, #0x6d65
       To avoid false positives (due to guessed relocation entries), signature is matched from the first window to the end of the overlapping window

Putting it all together: With all three scaling challenges overcome, we can start testing

                                                     1                                                              2
     Prepare patch test set                                                                             Test for patch presence

     Mount source code tree            Run source-code analysis        Generate build log               § Find and extract
     § Read manifest                   § Source-code patch analysis    § Run build system in dry-run      function (using
     § Fuse filesystem to read files     is much easier than binary      mode, don’t compile              symbol table or
       on demand                         analysis                        everything                       rolling signature)
                                       § Determines whether a          § Save log of all commands to    § Mask relocation
                                         signature match means that      be executed                      entries from
                                         the patch is applied or not   § Various hacks/fixes to build     signature
                                                                         system required                § Calculate and
                                                                                                          compare hash of
                                                                                                          remaining code
     Preprocess source files           Recompile with variants         Generate signatures
        § Use command
as Logo Horizontal
Pos / Neg
                        line from      § >50 different compiler        § Evaluate relocation entries
       saved build log                   binaries                        and create signatures for
     § Save preprocessor output        § All supported CPU types         each compiler variant
       in database                     § Optimization levels
                                         (e.g. -O2, -O3)
                                       § 3897 combinations in total,
                                         74 in our current optimized

Patch gap: Android vendors differ widely in their patch completeness
                                       Missed patches Vendor     Samples*   Notes
                                                      Google         Lots   – The tables shows the average number of missing
                                                      Sony           Few      Critical and High severity patches before the
                                            0 to 1                            claimed patch date
                                                      Samsung        Lots
                                                      Wiko           Few    * Samples – Few: 5-9; Many: 10-49; Lots: 50+
                     Vendors differ                   Xiaomi        Many    – Some phones are included multiple times with
                     in how many            1 to 3    OnePlus       Many      different firmwares releases
                     patches are                                            – Not all patch tests are always conclusive, so the
                                                      Nokia          Few
                     missing from                                             real number of missing patches could be higher
                     their phones                     HTC            Few
                                                                            – Not all patches are included in our tests, so the
                                                      Huawei        Many
                                            3 to 4                            real number could be higher still
                                                      LG            Many    – Only phones are considered that were patched
                                                      Motorola      Many      October-2017 or later
                                                      TCL           Many    – A missing patch does not automatically indicate
as Logo Horizontal                       More than 4
Pos / Neg                                             ZTE            Few      that a related vulnerability can be exploited

                     Some of the       Missed patches Chipset    Samples* Notes
                     patch gap is           < 0.5     Samsung        Lots – Again, we show the average of missing High and
                     likely due to          1.1      Qualcomm        Lots   Critical patches for phones that use these
                     chipset vendors                                        chipsets
                     forgetting to          1.9      HiSilicon      Many – Samsung phones can run on a Samsung or
                     include them           9.7      Mediatek       Many    Qualcomm chipset


                     § Research motivation

                     § Spot the Android patch gap

                     § Try to exploit Android phones

as Logo Horizontal
Pos / Neg

Can we now hack Android phones due to missing patches?

                                                                      Mobile operating systems are inherently
                At first glance, Android phones look hackable   VS.
                                                                      difficult to exploit
                § We find that most phones miss patches               § Modern exploit mitigation techniques
                  within their patch level                              increase hacking effort
                § While the number of open CVEs can be                § Mobile OSs explicitly distrust applications
                  smaller than the number of missing patches,           through sandboxing, creating a second layer
                  we expect some vulnerabilities to be open             of defense
                § Many CVEs talk of “code execution”,
as Logo Horizontal
Pos / Neg
                                                                      § Bug bounties and Pwn2Own offer relatively
                  suggesting a hacking risk based on what we            high bounties for full Android exploitation
                  experience on Windows computers

Do criminals hack Android? Very rarely.

                                                    Criminals generally use three different methods to compromise Android devices

                        Social engineering                            Local privilege escalation                     Remote compromise
                        Trick user into insecure actions:             § Trick user into installing malicious app     § Exploit vulnerability in an outside-
                        § Install malicious app                       § Then exploit kernel-level vulnerability to     facing app (messenger, browser)

         Approach       § Then grant permissions                        gain control over device, often using        § Then use local privilege escalation
                                                                        standard “rooting” tools
                        § Possibly request ‘device administrator’
                          role to hinder uninstallation

                        § Ransomware [File access permission]         § Targeted device compromise, e.g.             § (Google bug bounty, Pwn2Own)
         Used for       § 2FA hacks [SMS read]                          FinFisher and Crysaor (Same company
                                                                        as infamous Pegasus malware)
                        § Premium SMS fraud [SMS send]
as Logo Horizontal                                                    § Advanced malware
Pos / Neg
         Frequency in   § Almost all Android “Infections”             § Regular observed in advanced                 § Very few examples of recent
         criminal                                                       malware and spying                             criminal use

         Made harder
                                             û                                ü    (userland or kernel)                       ü    (userland and kernel)

An exploitable vulnerability implies a missing patch, but not the other way around

                         Missing patches in source code

                         Code parts that are ignored during compilation       Missing patches
                                                                           (source code analysis)

                     =   Missed patches in binary
                                                                             Missing patches
                                                                             (binary analysis)
                         Vendor created alternative patch

                         Vulnerability requires a specific configuration
as Logo Horizontal
                         Bug is simply not exploitable                        vulnerabilities
Pos / Neg

                         Errors in our heuristic (it happens!)

                     =   Open vulnerabilities

A single Android bug is almost certainly not enough for exploitation

                Android remote code execution is a multi-step process            Simplified exploit chain examples with 4 bugs
                       1 Information leakage is used to derive ASLR
                         memory offset (alternatively for 32-bit binaries,
                         this offset can possibly be brute-forces)                       1    Info leakage (IL)
                       2 Corrupt memory in an application. Examples:
                         - Malicious video file corrupts memory using
                           Stagefright bug                                                    Memory                   3a          4a
                         - Malicious web site leverages Webkit vulnerability                  corruption (MC)
                                                                                                                       IL          MC
                           Ø This gives an attacker control of the application
                             including the apps access permission                Application context
                     3 4 Do the same again with two more bugs to gain
as Logo Horizontal
Pos / Neg                access to system context or kernel                        3b
                                                                                                            System context
                           Ø This gives an attacker all possible permissions                    KASLR
                             (system context), or full control over the device     4b    MC
                             (kernel)                                                                             Kernel
                                                                                  Aside from exploiting MC and IL programming bugs, Android
                                                                                  has experienced logic bugs that can enable alternative, often
                                                                                  shorter, exploit chains
Remotely hacking a modern Android device usually requires chains of bugs
                                                              Application context                   System context              High privileged domain
                                                 Remote       protection mechanism                  protection mechanisms       (e.g. system-server,
                                                 attacker     (e.g. ASLR, sandbox)                  (e.g. ASLR, sandbox)        Bluetooth)
                                                                  1             2                       3          4
       Famed         Stagefright [2015]
       real-world    Android < 5.1.1                              X            DH
       exploit                                                                                                                        Weakness severities
       examples                                                                                                                              Critical
                     Return to libstagefright [2016]
                     Android < 7.0                               DH                       DH                      DH
                     BlueBorne [2017]                            Not needed: BNEP stack
                     Android < 8.0                                                                 SF       DH
                                                                  is addressed directly
                     Pixel - Nexus 6P [2017]
                     Chrome Android prior                        DH          DH SF                      X                             Weakness classes
                     Pixel [2018]                                                                                                       DH Data handling errors (CWE-19)
as Logo Horizontal
                     Chrome Android prior                        TS                           DH                                           e.g. buffer errors, input
Pos / Neg
                     61.0.3163.79                                                                                                          validation mistakes
                                                                                                                                        SF   Security features gaps (CWE-254)
                                                       Step 1: Remote Code Execution          Step 2: Escalation of Privilege                e.g. permission errors, privileges
                                                       and Information disclosure             At least one other weakness (or                mishandling, access control errors
                                                       In many cases, one critical or high-   the users themselves) helps the
                                                                                                                                        TS   Time and state errors (CWE-361)
                                                       severity weakness is exploited to      attacker overcome protection                   e.g. race conditions, incorrect
                                                       allow for Remote Code Execution        mechanisms and gain access to                  type conversions or casting
                                                       (RCE). (In the special case of         higher privileges
                                                       BlueBorne, no sandbox exists.)

In case you want to dive deeper: More details on well-documented Android exploit chains

                                                           1                            2                               3                             4
               Famed        Return to          Heap pointer leak to           ROP execution in             Module pointer leak to           Call mprotect to get
               real-world   libstagefright     bypass ASLR protection         mediaserver process          get address of executable        RCE into privileged
               exploit      2016                                                                           code                             system-server domain
                                                                                                                                       SF                             DH
                                               BlueBorne is a vulnerability in the           needed        Information leak                 Trigger memory
                                               Android Bluedroid/Fluorid userland stack,                   vulnerability leaks              corruption in BNEP
                                               which is already a high-privileged domain                   arbitrary data from              service that enables an
                                                                                                           the stack, which                 attacker to execute
                            2017                                                                           allows an attacker to            arbitrary code in the
                                                                                                           derive ASLR base                 high privileged
                                                                                                           address for a bypass             Bluetooth domain

                                                                        DH                                 DH                     SF                                  X
                                               Content view client in         Attacker perform arbitrary        Open intent             Exploit chain does not
as Logo Horizontal                             Chrome allowed                 read/write operations             controlled URL          include break-out of
Pos / Neg                   Pixel / Nexus 6P   arbitrary intent               leading to code execution         in Google Drive         untrusted app context
                            2017               scheme opening,                based on incorrect                to get shell in
                                               which allows escaping          optimization assumption           untrusted app
                                               the Chrome sandbox             in Chrome v8                      context

                                                                             TS                                                                                       DH
                                               Chrome V8 bug to get RCE           Use map and unmap mismatch in libgralloc to escape Chrome sandbox and
                            Pixel              in sandbox using a OOB             inject arbitrary code into system-server domain by accessing a malicious URL
                            2018               bug in GetFirstArgument-           in Chrome
                                               AsBytes function

SnoopSnitch version 2.0 introduces patch analysis for all Android users

          Tool name



          § [new in 2.0] Detect potentially
            missing Android security patches
          § Collect network traces on Android
            phone and analyze for abuse
          § Optionally, upload network traces to
            GSMmap for further analysis


          § Android version 5.0
as Logo Horizontal
Pos / Neg § Patch level analysis:
            All phones incl. non-rooted
          § Network attack monitoring:
            Rooted Qualcomm-based phone


                         Search: SnoopSnitch

Take aways

                     § Android patching is more complicated and less reliable than a single patch
                       date may suggest

                     § Remote Android exploitation is also more much complicated than
                       commonly thought

                     § You can finally check your own patch level thanks to binary-only analysis,
                       and the app SnoopSnitch

                     Many thanks to Ben Schlabs, Stephan Zeisberg, Jonas Schmid, Mark Carney,
as Logo Horizontal   Lukas Euler, and Patrick Lucey!
Pos / Neg

                                                                   Jakob Lell   
                                                                   Karsten Nohl 

            1. Federal Trade Commision, Mobile Security Updates: Understanding the Issues, February 2018

            2. Duo Labs Security Blog, 30% of Android Devices Susceptible to 24 Critical Vulnerabilities, June 2016

                3. Google, Android Security 2017 Year In Review, March 2018
as Logo Horizontal https://source.android.com/security/reports/Google_Android_Security_2017_Report_Final.pdf
Pos / Neg

You can also read
NEXT SLIDES ... Cancel