Investigating the 'RunAs' Password Length Local Information Disclosure Vulnerability

Have you ever heard about a 'benchmarking attack'? I decided to write about this particular type of attack due to the fact that it has recently been detected in Microsoft Windows. It is linked to the 'RunAs' Password Length Local Information Disclosure Vulnerability. So, if you are interested in finding out how this type of vulnerability is taken advantage of, don‘t skip this article. Microsoft Windows contains a 'RunAs' application that can be used to execute a second application as a different user, mainly in order to carry out privileged operations.

'RunAs' is prone to a local information disclosure vulnerability. Particularly, the application will prompt the current user for the password of a designated user. A local attacker able to control the 'I/O Other Bytes' performance of the application, might find out the length of the submitted password modulo 4. The attacker might then use this information in further attacks, like brute-force or dictionary attacks against passwords.

You may be wondering what I/O other bytes are? The answer from Microsoft, quoted from Task Manager's help is: "The number of bytes transferred in input/output operations generated by the process that are neither a read nor a write, including file, network and devices I/Os. An example of this type of operation is a control function".

'RunAs' is a critical component of Windows that is available on all the current Windows versions. It is also extensively used by administrators in corporate environments.

The attack allows a guest user to predict the password length listed by any user who ran 'RunAs' and typed a password in. This is easily done and is based on examining the I/O bytes computed while performing 'RunAs.exe'.

Benchmark attacks are slightly similar to timing attacks. Timing attacks include the analysis of the time it takes for a system to compute data, in order to predict private information about the specific data. So, with 'benchmark attacks' we are not only looking at how fast a process is running but also how effective it is. In order to figure this out you will have to depend on many different indicators, making the time a process runs only a part of a benchmark result. Therefore, 'Benchmarking attacks' are based on all the indicators that you can obtain to help examine the way a component is running.

Operating systems affected by the Vulnerability were confirmed and include Windows XP Pro, Windows 2003, Windows 2008, Windows Vista, all service packs and possibly some UNIX/Linux systems with some variants. Some of the files related to the vulnerable Windows Vista may include but are not limited to the following: apss.dll, miguiimg.dll, uddi-mig.dll, plamig.dll, cbsmsg.dll and diager.dll.

Now, it would be easy to put the full blame on 'RunAs.exe'. The software should pad the password to a huge and unchangeable length in order to hide the password length while computing it, but even if it did, it would still not be sufficient. It has become evident that 'benchmarking attacks' can work against a large number of softwares proceeding data in similar ways. The solution? well you can't exactly require developers to master time execution, memory allocation and I/O operations in order to hide and sensitive data. That would be ridiculous.

It should be noted that on Windows any unprivileged user is able to get information on highly privileged running processes. In other words, a process is able to access other process information just by watching its own available environment. This is where the major flaw exists. If an environment is secured it should be impenetrable and careful attention should be paid to what is revealed to other users or processes. This is clearly a problem Windows still needs to work on.