Retail and Consumer Goods

Lenovo released a new version of the Lenovo System Update advisory (https://support.lenovo.com/ar/es/product_security/lsu_privilege) about two new privilege escalation vulnerabilities I had reported to Lenovo a couple of weeks ago (CVE-2015-8109, CVE-2015-8110). IOActive and Lenovo have issued advisories on these issues.

Before digging into the details, let’s go over a high-level overview of how the Lenovo System Update pops up the GUI application with Administrator privileges.

Here is a discussion of the steps depicted above:

1 – The user starts System Update by running the tvsu.exe binary which runs the TvsuCommandLauncher.exe with a specific argument. Previously, Lenovo fixed vulnerabilities that IOActive discovered where an attacker could impersonate a legitimate caller and pass the command to be executed to the SUService service through named pipes to gain a privilege escalation. In the newer version, the argument is a number within the range 1-6 that defines a set of tasks within the dll TvsuServiceCommon.dll

2 – TvsuCommandLauncher.exe then, as usual, contacts the SUService service that is running with System privileges, to process the required query with higher privileges.

3 – The SUService service then launches the UACSdk.exe binary with System privileges to prepare to execute the binary and run the GUI interface with Administrator privileges.

4 – UACSdk.exe checks if the user is a normal unprivileged user or a Vista Administrator with the ability to elevate privileges.

5 – Depending on user privileges:

- For a Vista Admin user, the user’s privileges are elevated.
- For an unprivileged user, UACSdk.exe creates a temporary Administrator account with a random password which is deleted it once the application is closed.

The username for the temporary Administrator account follows the pattern tvsu_tmp_xxxxxXXXXX, where each lowercase x is a randomly generated lower case letter and each uppercase X is a randomly generated uppercase letter. A 19-byte, random password is generated.

Here is a sample of a randomly created user:

6 – Through tvsukernel.exe binary, the main Lenovo System Update GUI application is then run with Administrator privileges.

BUG 1 : Lenovo System Update Help Topics Privilege Escalation

The first vulnerability is within the Help system and has two entry points by which a user can open an online help topic that starts an instance of Internet Explorer.

1 – The link in the main application interface

2 – By clicking on the Help icon at top right and then clicking Settings

Since the main application Tvsukernel.exe is running as Administrator, the web browser instance that starts to open a Help URL inherits the parent Administrator privileges.

From there, an unprivileged attacker has many ways to exploit the web browser instance running under Administrator privileges to elevate his or her own privileges to Administrator or SYSTEM.

BUG 2 : Lenovo System Weak Cryptography Function Privilege Escalation

Through a more technical bug and exploitable vulnerability, the temporary administrator account is created in specific circumstances related to Step 5b in the overview.

The interesting function for setting the temporary account is sub_402190 and contains the following important snippets of code:

The function sub_401810 accepts three arguments and is responsible for generating a random string pattern with the third argument length.

Since sub_401810 generates a pattern using RAND, the initialization of the seed is based on the addition of current time and rand values and defined as follows:

Once the seed is defined, the function generates the random value using a loop with RAND and division/multiplication with specific values.

Rather than posting the full code, I’ll note that a portion of those loops looks like the following:

The first call to this function is used to generate the 10-letter suffix for the Administrator username that will be created as “tvsu_tmp_xxxxxXXXXX”

Since it is based on rand, the algorithm is actually predictable. It is possible for an attacker to regenerate the same username based on the time the account was created.

To generate the password (which is more critical), Lenovo has a more secure method: Microsoft Crypto API (Method #1) within the function sub_401BE0. We will not dig into this method, because the vulnerability IOActive discovered is not within this function. Instead, let’s look at how Method #2 generates a password, if Method #1 fails.

Let’s return to the snippets of code related to password generation:

We can clearly see that if function sub_401BE0 fails, the execution flow fails back using the custom RAND-based algorithm (defined earlier in function sub_401810) to generate a predictable password for the temporary Administrator account. In other words, an attacker could predict the password created by Method #2.

This means an attacker could under certain circumstances predict both the username and password and use them to elevate his or her privileges to Administrator on the machine.

Since speaking at BlackHat DC 2009, there have been several inquiries in regards to the security of the SLE66PE series smartcard family.

Here are some issues that should be pointed out:

We have heard, “..it took 6 months to succeed..“

The reality is it took 4 months to tackle obsticles found in any <200nm device such as:

Capitance/load of probe needles when chip is running.
Powering the device inside the chamber of a FIB workstation.
Level-shifting a 1.8v core voltage following what we learned in #1 above.
Cutting out metal layers without creating electrical shorts.
Other more minute issues regarding the physical size of the die.

Upon overcoming the points above, the actual analysis required no more than approximately 2 months time.

In addition, these techniques listed above apply to all devices in the <200nm category (SecureAVR, SmartMX, ST21, ST23).

We have heard, “…you said the Infineon SLE66 was the best device out there in the market…“

The Infineon SLE66PE is a very secure device however, it (as do it’s competitors) all have their strengths and weaknesses.

Some examples of weaknesses are

Layout of all Infineon SLE50/66 ‘P’ or ‘PE’ are very modular by design
Lack of penalty if active shield is opened
Begin runtime from a CLEAR (unencrypted) ROM which is ‘invisible’ to the user
CPU core is based on a microcode/PLA type implementation
Power-on-reset always begins running from the externally supplied clock
Current design is based on a previous 600nm version designed around 1998
3 metal layer design for “areas of interest” (4th layer is the active shield)

Some examples of strengths are:

‘PE’ family used bond-pads located up the middle of the device.
ROMKey must be loaded before begin attacked (else you just see their clear ROM content).
MED is quite powerful if used properly for EEPROM content.
Mesh is consistent across the device and divided into sections.
Auto-increment of memory base address.
Mixing of physical vs. virtual address space for MED / memory fetch.

No device is perfect. All devices have room for improvement. Some things to consider when choosing a smartcard are:

Does CPU ever run on external clock?
What is the penalty for an active-shield breach?
What is the fabrication process geometry?
How many metal layers is the device?
List of labs who might have evaluated this device and their capabilities.

Lastly, just because the device has been Common Criteria certified does not mean much to an attacker armed with current tools. This is a common-oversight.

There is an ST23 smartcard device which has recently been certified EAL-6+ and the device has an active-shield with almost 1 micron wide tracks and a 1-2 micron spacing!!! This makes a person scratch there head and say, “WTH????”

We have some new content to post soon on the blog. Be sure and tune in for that. We will tweet an alert as well.

Tag: Retail and Consumer Goods

Privilege Escalation Vulnerabilities Found in Lenovo System Update

Blackhat TPM Talk Follow-up