MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ibf56827209a9b791aa83ae679219baf829ffc2ac
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: I1004579181ff7a223ef659e85c46100c47ab2409
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Id7f0e8a4c861b0b9fa796767e0c22d96633b14d1
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ie267646eb88014034fbd048d7a9bc273420c7eff
Instead of relying on the window animation system, in the special
case of a swipe-dismiss, disable any default window exit animation
and perform a custom animation. This bypasses some bugs in the
window animator codebase and allows us to have a nice "rebound"
animation if the user doesn't swipe far/fast enough to trigger a
dismiss.
Bug: 33041168
Change-Id: Ied45700d35a59950bacef1ba0650eaa5bc60fadb
If permission review is enabled toggling bluetoth on or off
results in a user prompt to collect consent. This applies
only to legacy apps, i.e. ones that don't support runtime
permissions as they target SDK 22.
Also added a configuration resource which controls whether
permission review mode is enabled. By default it is not and
an OEM can change this via an overlay. For now we also keep
the old mechanism to toggle review mode via a build property
which is still used and will be removed when clients have
transitioned.
bug:28715749
Change-Id: I94c5828ad6c8aa6b363622a26ff9da4fc2e2fac7
As part of fixing a recent security issue, DownloadManager now needs
to issue Uri permission grants for all downloads. However, if an app
that requested a download is upgraded or otherwise force-stopped,
the required permission grants are removed.
We could tell DownloadManager about the app being stopped, but that
would be racy (due to background broadcast), and waking it up would
degrade system health. Instead, as a special case we now only
consider clearing DownloadManager permission grants when app data
is being cleared.
Bug: 32172542, 30537115
Test: builds, boots, app upgrade doesn't clear grants
Change-Id: I7e3d4546fd12bfe5f81b9fb9857ece58d574a6b9
(cherry picked from commit 23ec811266)
As part of fixing a recent security issue, DownloadManager now needs
to issue Uri permission grants for all downloads. However, if an app
that requested a download is upgraded or otherwise force-stopped,
the required permission grants are removed.
We could tell DownloadManager about the app being stopped, but that
would be racy (due to background broadcast), and waking it up would
degrade system health. Instead, as a special case we now only
consider clearing DownloadManager permission grants when app data
is being cleared.
Bug: 32172542, 30537115
Test: builds, boots, app upgrade doesn't clear grants
Change-Id: I7e3d4546fd12bfe5f81b9fb9857ece58d574a6b9
(cherry picked from commit 23ec811266)
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
