commonsguy/cwac-security

CWAC-Security: Helping You Help Your Users Defend Their Data

cwac-security's Issues

FlagSecureHelper: Test Native Toolbar

Toolbar may be covered by the action bar fixes, but it may not. Test its overflow and putting a ShareActionProvider in it.

How to secure communication between two peer apps?

First, very sorry if this is not the place for this comment/discussion, but I've read your blog post and your paper and couldn't find any spot to leave a comment...

Your description of the flaws of the custom permissions system is very interesting, and as it seems, Android devs tried to fix it in Android L. But the "fix" (only apps signed with the same certificate can re-define the same permission) brings new problems...

Let's tell you about my own situation: I develop a "controller" app for a new gaming accessory. All kinds of 3rd party apps (games) can use my accessory by binding to the service of my "controller", but those 3rd party games are also standalone, so the order of installation shouldn't matter!

I could make the 3rd party developers redefine the permission in their Manifest, but this ability will apparently break in Android L...

What do you recommend, as techniques to secure communications between apps, maybe without the custom permissions system?
Thanks very much.

David

clear flags

If the APP has some fragment in the one ViewPager from one Activity and we needs block screenshot in just one these fragments, the SECURE_FLAG is apply in all Fragments and clearFlag doesn´t works .
How we can fix this ?

Error during gradle sync

implementation 'com.commonsware.cwac:security:0.8.0'
url "https://s3.amazonaws.com/repo.commonsware.com"
Error occured during sync
ERROR: Unable to resolve dependency for ':app@debug/compileClasspath': Could not resolve com.commonsware.cwac:security:0.8.0.

ZipUtils' rollback may delete unwanted data

The current implementation of ZipUtils deletes the whole destDir when an exception occurs.

I can see developers unzipping stuff into a directory already containing files and loosing everything cause of this.

I'm not sure what would be the best approach:

1-Make a list of extracted files and delete only them instead of the whole directory (this may still cause issues with already existent, overwritten files).

2-Unzip into a temp directory and, if no errors detected, move everything into destDir (maybe with an optional boolean flag to allow/deny overwriting already existing files).

3-Leave as is but provide a better documentation (or warning somewhat) the "I will delete everything on fail".

Failed to list versions for com.commonsware.cwac:security

Hi,

We were using the com.commonsware.cwac:security, and the code built successfully until Dec. 7th 2021.

Now, when we try to build, we got the following exception:
> Failed to list versions for com.commonsware.cwac:security. > Unable to load Maven meta-data from http://dl.bintray.com/amulyakhare/maven/com/commonsware/cwac/security/maven-metadata.xml. > Could not get resource 'http://dl.bintray.com/amulyakhare/maven/com/commonsware/cwac/security/maven-metadata.xml'. > Could not GET 'http://dl.bintray.com/amulyakhare/maven/com/commonsware/cwac/security/maven-metadata.xml'. Received status code 502 from server: Bad Gateway
Seems the package is not accessible anymore.

May I ask you to have a check on it? If it get relocated, may I ask what is the new path?

Thank you very much.

FlagSecureHelper: Test appcompat-v7

Create a new test activity that uses AppCompatActivity, Theme.AppCompat, etc. Also migrate to it for the action bar. Test everything on it, to ensure that the action bar backport and widget wrappers are still covered by my fixes, and that my fixes do not collide with any trickeration performed by appcompat-v7. Test this on 23.4.0 with plans to test again on future versions of the library.

FlagSecureHelper: MENU Key-Driven Overflow Not Protected

On the Galaxy Note 3 (Android 5.0 test case), the device has a MENU key. The overflow rises from the bottom of the screen rather than drops down, and it is not protected.

Pre-initialize certificate memorization

Allow certs to be pre-loaded into the memorization roster, as an alternative to the existing limited TOFU support. This might be automatic for self-signed certs.

Support CA Pinning

Moxie Marlinspike's implementation supports N pins (we only need one pin, rest achieved through or()) and is GPLv3 licensed.

Also consider a Java version of the pin creation tool, since Windows users are unlikely to have Python installed.

Support Guardian Project's CACert

https://github.com/guardianproject/cacert

Since this is a raw resource, at best it would only be available out of the box in the AAR packaging.

FlagSecureHelper: Test App Context Menus

onCreateContextMenu() and kin. See if this popup is protected.

FlagSecureHelper: Spinner "Dialog Mode" Not Protected

android:spinnerMode="dialog" is not being addressed by the current FlagSecureHelper implementation. Preliminary indications are that this will not be possible to support.

Implement VettedContextWrapper, VettedActivity, and kin

These classes would validate inbound Intents (e.g., onCreate()/onNewIntent() of activity, onHandleIntent() of service) and outbound Intents (e.g., startActivity()), to confirm that they conform to a configurable set of policies, to confirm that the partner app is someone that we trust.

Have an VettingPolicyBuilder to construct a chain of such rules, based upon the model used with TrustPolicyBuilder. Stock policies should include:

• Partner signature hash matches pinned value
• Partner signature hash matches previously-seen value (trust-on-first-use/memorization), with optional "hey! this is first use!" hooks for user confirmation
• Partner whole-APK hash matches pinned value
• Partner whole-APK hash matches previously-seen value (trust-on-first-use/memorization), with optional "hey! this is first use!" hooks for user confirmation
• Partner holds certain permissions (for cases where android:permission is insufficient, such as holding N permissions)

Ensure that the policies have enough hooks for app-specific Intent content rules (e.g., secrets leakage via extras).

Ensure that the policies also support a "conditional-trust-on-first-use" model, where we soft fail (to allow the UI to alert the user for a validation check), then can validate the request in a background thread. For example, this would support an online catalog of known signature/whole-APK hashes. This would also be useful for a licensing check (e.g., will only inter-operate with third parties publishing a per-package license key in a well-known location, with Web service check of license key). Ideally, have some sort of cache of this stuff, so we can avoid the "conditional" part via a preload (e.g., we only interoperate with confirmed-good plugins for our hub-and-spoke model, where we download the roster of plugins periodically).

For outbound requests, this implies an explicit Intent, so we know who the partner is. Provide an VettedActionProvider and a VettedChooser to help with this. If handed an implicit Intent, fail if there are multiple matching components (e.g., queryIntentActivities()).

For inbound requests, use Binder.getCallingUid(). Policies should indicate whether we support N apps with a shared user ID for callers (and, if so, how do we interpret the rest of the policies?).

Provide base classes (e.g., VettedActivity) that apply this stuff automatically. For outbound requests, can use a VettedContextWrapper as well. Everything should be available without inheritance though -- the base classes should be for convenience, nothing more.

The serious PITA will be working up a test harness for this.

This stuff is based on Facebook's presentation of having similar capabilities in their app, which (AFAIK) they have not (yet) released as open source.

Be smarter with duplicate or() and and() calls

Something like selfSigned(...).or().selfSigned(...).or().useDefault() should work. However, it will create three chained CompositeTrustManager instances, when we only need one.

The first or() should see that the current CompositeTrustManager has only one child, and therefore it can safely be converted from match-all to match-any mode.

The second or() should see that the current CompositeTrustManager is already in match-any mode, so we don't need to wrap it in another one.

Similar optimizations are available for and() as well.

FlagSecureHelper: Test PopupWindow/ListPopupWindow/PopupMenu

Both native and appcompat-v7.

https://github.com/FutureMind/recycler-fast-scroll

FlagSecureHelper: Ponder EditText Floating Action Mode

Reports are that this is not covered. Confirm this (can it be tested in AutoCompleteTextView?) and then see what might be done.

PermissionUtils: handle signature level but different signing key scenario

https://code.google.com/p/android/issues/detail?id=65864#c3

If the defender has a signature permission, and an attacker previously defines the same permission also as signature (but with a different signing key), PermissionUtils does not report a problem. This should be included in the analysis.

FlagSecure: Protect Legacy Context Menus

The menu raised by registerForContextMenu() or showContextMenu() is not protected by the existing version of the FlagSecureHelper logic. Identify how this window is being created and figure out how to add FLAG_SECURE to it.

Logic error in PermissionUtils

Hi Mark,

As I read the code I think there is a logic error here.
code does this (more or less)

1. get current package permissions as declared in
2. get all packages and their permissions
3. for each package that is not the currrent package
   3a. for each of my permissions
   3b. compare them, in particular compare the protectionLevel

Here I think is the flaw:

It's not enough to compare the protectionLevel, consider:

First BadApp declares and requests sig permission X, same label, same description
Second GoodApp declares and protects itself with sig permission X

This should succeed because Android uses BadApps defintion and GoodApp never requests X so the install will succeed.

Now in the logic above (3b) the protectionLevel will either compare equal (or if X is not in GoodApp;s structure the comparison will never happen).

Either way the caveat for PermissionUtils to work is that GoodApp must also request X.

If it does so then install of X will fail and PermissionUtils need not handle this case.

Caveat: I have not tested this - it's just from skimming the code.

FlagSecureHelper - Launcher Activity View Binding Crash - Android 11

CWAC Security Library Use Details

cwac security version: 0.8.0
cwac security functionality involved: FLAG_SECURE/FlagSecureHelper as described here with the getSystemService() override as specified below.

@Override
public Object getSystemService(String name) {
  Object result=super.getSystemService(name);

  return(FlagSecureHelper.getWrappedSystemService(result, name));
}

Bug Description

When using view binding in the launcher Activity, the getSystemService() code (FlagSecureHelper.getWrappedSystemService(result, name)) results in a crash on Android 11/R (api 30) using any combination of views in the layout. However, the crash doesn't happen at that line of code. Instead, the crash is triggered by the line trying to inflate the binding layout (LayoutBinding.inflate(layoutInflator)). Commenting out the getSystemService() override method fixes the issue. Additionally, it appears to only cause a crash on the initial/launcher Activity as another, later launched, Activity appears to use view binding without issue.

Reproducing

I created a basic project to verify the issue. Running the project on an Android 11 device will result in the crash below. Commenting out the getSystemService() method in MainActivity will fix the issue.

Please let me know if I can provide any other details to help, and thank you for your security work on the Android platform.

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.example.myapplication/com.example.myapplication.MainActivity}: android.view.InflateException: Binary XML file line #2 in com.example.myapplication:layout/activity_main: Binary XML file line #2 in com.example.myapplication:layout/activity_main: Error inflating class android.widget.LinearLayout
        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3449)
        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3601)
        at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:85)
        at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
        at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2066)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loop(Looper.java:223)
        at android.app.ActivityThread.main(ActivityThread.java:7656)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
     Caused by: android.view.InflateException: Binary XML file line #2 in com.example.myapplication:layout/activity_main: Binary XML file line #2 in com.example.myapplication:layout/activity_main: Error inflating class android.widget.LinearLayout
     Caused by: android.view.InflateException: Binary XML file line #2 in com.example.myapplication:layout/activity_main: Error inflating class android.widget.LinearLayout
     Caused by: java.lang.reflect.InvocationTargetException
        at java.lang.reflect.Constructor.newInstance0(Native Method)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:343)
        at android.view.LayoutInflater.createView(LayoutInflater.java:852)
        at android.view.LayoutInflater.createView(LayoutInflater.java:774)
        at com.android.internal.policy.PhoneLayoutInflater.onCreateView(PhoneLayoutInflater.java:58)
        at android.view.LayoutInflater.onCreateView(LayoutInflater.java:928)
        at android.view.LayoutInflater.onCreateView(LayoutInflater.java:948)
        at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:1002)
        at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:959)
        at android.view.LayoutInflater.inflate(LayoutInflater.java:657)
        at android.view.LayoutInflater.inflate(LayoutInflater.java:532)
        at com.example.myapplication.databinding.ActivityMainBinding.inflate(ActivityMainBinding.java:37)
        at com.example.myapplication.databinding.ActivityMainBinding.inflate(ActivityMainBinding.java:31)
        at com.example.myapplication.MainActivity.onCreate(MainActivity.kt:14)
        at android.app.Activity.performCreate(Activity.java:8000)
        at android.app.Activity.performCreate(Activity.java:7984)
        at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1309)
        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3422)
        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3601)
        at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:85)
        at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
        at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2066)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loop(Looper.java:223)
        at android.app.ActivityThread.main(ActivityThread.java:7656)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
     Caused by: java.lang.UnsupportedOperationException
com.example.myapplication E/AndroidRuntime:     at android.view.WindowManager.getMaximumWindowMetrics(WindowManager.java:481)
        at android.view.ViewConfiguration.<init>(ViewConfiguration.java:423)
        at android.view.ViewConfiguration.get(ViewConfiguration.java:520)
        at android.view.View.<init>(View.java:5317)
        at android.view.View.<init>(View.java:5467)
        at android.view.ViewGroup.<init>(ViewGroup.java:697)
        at android.widget.LinearLayout.<init>(LinearLayout.java:254)
        at android.widget.LinearLayout.<init>(LinearLayout.java:250)
        at android.widget.LinearLayout.<init>(LinearLayout.java:246)
        	... 29 more

Support certificate memorization

Support both blind trust-on-first-use and a custom exception (if caller wants to prompt user for that). Also custom exception on memorization mismatch for prompting.

Work together on a unified SSL library

While this might not be the ideal medium to communicate this, I think it would be a good idea to unify our work on providing a superior SSL/TLS library for handling different situations.

Currently, we have:

• moxie's AndroidPinning
• my MTM
• fdroid's adaptation of MTM for some custom use cases
• a great proposal by the GuardianProject: Chained TLS Cert Verification

It would be great if we could unify our resources to provide one easy to use library for the most common use cases (private server, private CA, private cloud), while implementing the Chained approach as far as possible.

can not resolve method open

from this: https://github.com/commonsguy/cwac-security/blob/master/TrustManagerBuilder.markdown
i used:
TrustManagerBuilder builder=new TrustManagerBuilder();

// configure builder here

SSLContext ssl=SSLContext.getInstance("TLS")

ssl.init(null, builder.buildArray(), null);

OkHttpClient okHttpClient=new OkHttpClient();

okHttpClient.setSslSocketFactory(ssl.getSocketFactory());

HttpURLConnection conn=okHttpClient.open(new URL(url));

But on HttpURLConnection conn=okHttpClient.open(new URL(url)); i get this error: "can not resolve method open"

FlagSecureHelper: Test Snackbar

In the appcompat-v7 test activity, add in an action bar item to display a Snackbar from design, then see if that is protected.