The path-permission element offers prefix or regex style matching of
paths, but most providers internally use UriMatcher to decide what
to do with an incoming Uri.
This causes trouble because UriMatcher uses Uri.getPathSegments(),
which quietly ignores "empty" paths. Consider this example:
<path-permission android:pathPrefix="/private" ... />
uriMatcher.addURI("com.example", "/private", CODE_PRIVATE);
content://com.example//private
The Uri above will pass the security check, since it's not
technically a prefix match. But the UriMatcher will then match it
as CODE_PRIVATE, since it ignores the "//" zero-length path.
Since we can't safely change the behavior of either path-permission
or UriMatcher, we're left with recovering these shady paths by
trimming away zero-length paths.
Bug: 112555574
Test: cts-tradefed run cts -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AppSecurityTests
Change-Id: Ibadbfa4fc904ec54780c8102958735b03293fb9a
Make sure the number of entries written by Parcel#writeMapInternal
matches the size written. If a mismatch were allowed, an exploitable
scenario could occur where the data read from the Parcel would not
match the data written.
Fixes: 112859604
Test: cts-tradefed run cts -m CtsOsTestCases -t android.os.cts.ParcelTest
Change-Id: I325d08a8b66b6e80fe76501359c41b6656848607
Merged-In: I325d08a8b66b6e80fe76501359c41b6656848607
The crash was introduced by Ib66ef392c19c937718e7101f6d48fac3abe51ad0
The root cause of the crashing is requesting out-of-line access for the
horizontal width. This invalid access is silently ignored by
TextLine#measure() method but new implementation end up with out of
bounds access.
To makes behavior as old implementation, calling getHorizontal instead
of accessing measured result array.
Bug: 78464361, 111580019
Test: Manually done
Change-Id: I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8
(cherry picked from commit 960647d582)
Merged-In: I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8
Developers often accept selection clauses from untrusted code, and
SQLiteQueryBuilder already supports a "strict" mode to help catch
SQL injection attacks. This change extends the builder to support
update() and delete() calls, so that we can help secure those
selection clauses too.
Bug: 111085900
Test: atest packages/providers/DownloadProvider/tests/
Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Change-Id: Ib4fc8400f184755ee7e971ab5f2095186341730c
Merged-In: Ib4fc8400f184755ee7e971ab5f2095186341730c
SQLiteQueryBuilder has a setStrict() mode which can be used to
detect SQL attacks from untrusted sources, which it does by running
each query twice: once with an extra set of parentheses, and if that
succeeds, it runs the original query verbatim.
This sadly doesn't catch inputs of the type "1=1) OR (1=1", which
creates valid statements for both tests above, but the final executed
query ends up leaking data due to SQLite operator precedence.
Instead, we need to continue compiling both variants, but we need
to execute the query with the additional parentheses to ensure
data won't be leaked.
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Bug: 111085900
Change-Id: I6e8746fa48f9de13adae37d2990de11c9c585381
Merged-In: I6e8746fa48f9de13adae37d2990de11c9c585381
* changes:
[automerger] Optimise the hit test algorithm am: 71ecf5bd5c am: 42eaa8f932
[automerger] Optimise the hit test algorithm am: 71ecf5bd5c
Optimise the hit test algorithm
Layout#getOffsetForHorizontal was running in O(n^2) time, where n is the
length of the current line. The method is used when a touch event
happens on a text line, to compute the cursor offset (and the character)
where it happened. Although this is not an issue in common usecases,
where the number of characters on a line is relatively small, this can
be very inefficient as a consequence of Unicode containing 0-width
(invisible) characters. Specifically, there are characters defining the
text direction (LTR or RTL), which cause our algorithm to touch the
worst case quadratic runtime. For example, a person is able to send a
message containing a few visible characters, and also a lot of these
direction changing invisible ones. When the receiver touches the message
(causing the Layout#getOffsetForHorizontal method to be called), the
receiver's application would become not responsive.
This CL optimizes the method to run in O(n) worst case. This is achieved
by computing the measurements of all line prefixes at first, which can
be done in a single pass. Then, all the prefix measurement queries will
be answered in O(1), rather than O(n) as it was happening before.
Bug: 79215201
Test: manual testing
Change-Id: Ib66ef392c19c937718e7101f6d48fac3abe51ad0
Merged-In: Ib66ef392c19c937718e7101f6d48fac3abe51ad0
* limit the absolute maximum size of the label to 50000 characters
[which is probably far more than necessary, but, can be dialed down]
* use a string buffer while processing the string [instead of creating
multiple string objects]
Bug: 62537081
Test: Manual. Install APK in bug and see that it can be uninstalled
Change-Id: Ibf63c2691ad7438a123e92110d95b1f50050f8b1
Merged-In: Ibf63c2691ad7438a123e92110d95b1f50050f8b1
