A vulnerability exists in Android 5.x <= 5.1.1 (before build LMY48M) that allows an attacker to crash the lockscreen and gain full access to a locked device, even if encryption is enabled on the device. By manipulating a sufficiently large string in the password field when the camera app is active an attacker is able to destabilize the lockscreen, causing it to crash to the home screen. At this point arbitrary applications can be run or adb developer access can be enabled to gain full access to the device and expose any data contained therein.

September 2015: Elevation of Privilege Vulnerability in Lockscreen (CVE-2015-3860)

The attack requires the following criteria:

• Attacker must have physical access to the device
• User must have a password set (pattern / pin configurations do not appear to be exploitable)

Proof-of-concept – Nexus 4 factory image 5.1.1 (build LMY48I):

---

Attack breakdown:

1. From the locked screen, open the EMERGENCY CALL window.
   
   
2. Type a few characters, e.g. 10 asterisks. Double-tap the characters to highlight them and tap the copy button. Then tap once in the field and tap paste, doubling the characters in the field. Repeat this process of highlight all, copy, and paste until the field is so long that double-tapping no longer highlights the field. This usually occcurs after 11 or so repetitions.
   
   
3. Go back to the lockscreen, then swipe left to open the camera. Swipe to pull the notification drawer down from the top of the screen, then tap the Settings (gear) icon in the top right. This will cause a password prompt to appear.
   
   
4. Long-tap in the password field and paste the characters into it. Continue to long-tap the cursor and paste the characters as many times as possible, until you notice the UI crash and the soft-buttons at the bottom of the screen disappear, expanding the camera to fullscreen. Getting the paste button can be finicky as the string grows. As a tip, always make sure the cursor is at the very end of the string (you can double-tap to highlight all then tap towards the end to quickly move the cursor there) and long-tap as close to the center of the cursor as possible. It may take longer than usual for the paste button to appear as you long-tap.
   
   
5. Wait for the camera app to crash and expose the home screen. The duration and result of this step can vary significantly but the camera should eventually crash and expose sensitive functionality. You should notice the camera lagging as it attempts to focus on new objects. Taking pictures via the hardware keys may speed up the process, though it is not strictly necessary. If the screen turns off due to inactivity, simply turn it back on and continue waiting. In some cases the camera app will crash directly to the full home screen as seen below, whereas other times it may crash to a partially rendered homescreen as seen in this alternate proof-of-concept video.
   
   
6. Navigate to the Settings application by any means possible, e.g. by tapping the app drawer button in the bottom center and finding it in the app list. At this point it is possible to enable USB debugging normally (About phone > tap Build number 7 times, back, Developer options > USB debugging) and access the device via the adb tool to issue arbitrary commands or access the files on the device with the full permissions of the device owner.
   

---

Timeline:

2015-06-25: Vulnerability reported privately to Android security team.
2015-07-01: Android confirms vulnerability can be reproduced, assigns LOW severity issue.
2015-07-15: Android promotes issue to MODERATE severity.
2015-08-13: Android commits a patch to fix vulnerability.
2015-09-09: Android releases 5.1.1 build LMY48M containing fix.
2015-09-14: Android marks issue public.
2015-09-15: UT ISO publishes this writeup.

– jgor

A vulnerability exists in Webmin <= 1.680 (CVE-2014-2952) that allows authenticated users to delete arbitrary files on the host server as root. The problem exists in the cron module, specifically in creating a new environment variable (System > Scheduled Cron Jobs > Create a new environment variable), in the “user” parameter. Here’s the normal request to create an environment variable:

Using directory traversal and null byte injection techniques we’re able to force webmin to delete any file on the filesystem. Modifying our request a bit:

..and the response:

We get an error, but this request also immediately deletes /etc/passwd on the server. Why? Let’s take a look at the relevant code in /usr/share/webmin/cron/save_env.cgi:

We get a list of files in the cron directory, then call lock_file() on each file. Note that the filename is constructed from the value of the user parameter then passed unsanitized to lock_file(). The purpose of lock_file(), defined in web-lib-funcs.pl, is to create a file of the form /path/to/filename.lock to indicate the file is in use. We can see the lock file being created on line 5202 of /usr/share/webmin/web-lib-funcs.pl:

Looking further down lock_file():

On line 5231 it’s storing the filename in locked_file_list, and on 5232 it gets added to temporary_files as well. These data structures come into play when webmin throws the error we saw earlier. Taking a look at the end of the error() function in web-lib-funcs.pl, we see:

First let’s take a look at unlock_all_files():

It iterates through locked_file_list calling unlock_file() on each filename. Now on to unlock_file():

Line 5283 calls unlink() on the filename with “.lock” appended, to delete the lock file. However since we injected a null byte at the end of the filename, everything after the %00 gets ignored. This means the real file, ../../../../etc/passwd, gets passed to unlink() and deleted.

The damage is already done but even if the unlock_all_files() call were not present cleanup_tempnames() would do the same job. Let’s take a look:

Again we’re iterating through the list of files, in this case temporary_files, and calling unlink on the file. Even though the filenames stored in temporary_files were added with “.lock” appended, our null byte knocked that off and stored ../../../../etc/passwd instead, which of course causes /etc/passwd to be deleted.

---

Timeline:

2014-05-14: UT ISO reports the vulnerability to Webmin developer Jamie Cameron as well as CERT. CERT reserves CVE-2014-2952 for the vulnerability.
2014-05-14: Jamie patches Webmin on github.
2014-05-20: Webmin 1.690 is released with the fix.
2014-09-09: UT ISO publishes this writeup.

– jgor