1181f448c1a0705328a5593810100946e0c3e0dd |
|
09-Dec-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fix vulnerability in MemoryIntArray 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
/frameworks/base/core/tests/utiltests/src/android/util/RemoteMemoryIntArrayService.java
|
43966dafb3d3b2d04ac7e63198cd42047df00969 |
|
08-Dec-2016 |
Bill Napier <napier@google.com> |
Revert "Fix vulnerability in MemoryIntArray am: a97171ec49" This reverts commit fb12dd509f8e106d034f67c2e404845128128994. Change-Id: I9e1b22b8df0e754095541a758096cba279a81ab1
/frameworks/base/core/tests/utiltests/src/android/util/RemoteMemoryIntArrayService.java
|
a97171ec499fd876722733f35e51d0d6dbd8d223 |
|
08-Dec-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fix vulnerability in MemoryIntArray 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
/frameworks/base/core/tests/utiltests/src/android/util/RemoteMemoryIntArrayService.java
|
1f06508bc640b90e613179f6371f53b9a839fa53 |
|
08-Dec-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Revert "Fix vulnerability in MemoryIntArray" This reverts commit 4694cad51122c20880d00389ef95833d7a14b358. Change-Id: I235ea3c4bd86d90bf97bc1a2d023f4780251e570
/frameworks/base/core/tests/utiltests/src/android/util/RemoteMemoryIntArrayService.java
|
4694cad51122c20880d00389ef95833d7a14b358 |
|
08-Dec-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fix vulnerability in MemoryIntArray 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
/frameworks/base/core/tests/utiltests/src/android/util/RemoteMemoryIntArrayService.java
|
29139a8ae51110b0cd9d6249f643364849d401c9 |
|
08-Dec-2016 |
Aart Bik <ajcbik@google.com> |
Revert "Fix vulnerability in MemoryIntArray" This reverts commit 86dfa094de773670743d41c3e3156eace8e403a3. BROKE BUILD (as shown in some treehugger builds) frameworks/base/core/java/android/util/MemoryIntArray.java:84: error: cannot find symbol mCloseGuard.open("close"); ^ bug:33039926 bug:33042690 Change-Id: Ief875e543ec849fe55c747fb1ed5253f0cd9a122
/frameworks/base/core/tests/utiltests/src/android/util/RemoteMemoryIntArrayService.java
|
86dfa094de773670743d41c3e3156eace8e403a3 |
|
08-Dec-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fix vulnerability in MemoryIntArray 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
/frameworks/base/core/tests/utiltests/src/android/util/RemoteMemoryIntArrayService.java
|
04df738bcb6584dd82b731a67f4cf8d6925b061e |
|
11-May-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Make settings cahches generation mechanism robust. Settings is using a MemoryIntArray to communicate the settings table version enabling apps to have up-to-date local caches. However, ashmem allows an arbitrary process with a handle to the fd (even in read only mode) to unpin the memory which can then be garbage collected. Here we make this mechanism fault tolerant against bad apps unpinning the ashmem region. First, we no longer unpin the ashmem on the client side and if the ashmem region is purged and cannot be pinned we recreate it and hook up again with the local app caches. The change also adds a test that clients can only read while owner can read/write. bug:28764789 Change-Id: I1ef79b4b21e976124b268c9126a55d614157059b
/frameworks/base/core/tests/utiltests/src/android/util/RemoteMemoryIntArrayService.java
|