Re: HP Quality Center vulnerability

2009-02-25 Thread Pavel Kankovsky
On Mon, 23 Feb 2009 i...@exposit.co.uk wrote:

 The front-end of the application is composed of COM components that plug
 into the web browser. [...]
 In order to optimize the interaction speed of the application, a cache
 folder is created on the client machine. [...] Indeed, those files are
 required on the client machine because the workflow is execute on the
 client, not on the server. [...]
 If a user modifies this file and then mark it as read-only, he can
 execute arbitrary code. As the OTA API allows access to the database, he
 can also modify the data stored in the database as follows:

You say you can execute arbitrary code on your computer (under your own 
account)? What an amazing exploit! (pun intended)

Any client-server application depending on the client side not being
messed with by its user is *broken by design*. It does not matter
whether the messing in question is easy (like putting a VB script in the
right directory) or difficult (like attaching a debugger to a running
process and flipping bits in its memory space).

 Please note that HP has released a patch that fixes this issue, please 
 contact HP support for further details.

I wonder what kind of fix has been released. Does anyone think they solved 
the REAL problem?

-- 
Pavel Kankovsky aka Peak  / Jeremiah 9:21\
For death is come up into our MS Windows(tm)... \ 21th century edition /



HP Quality Center vulnerability

2009-02-23 Thread info
Find below the details of a vulnerability in the HP Quality Center product 
(formely Mercury Quality Center).

Introduction
--

Quality Center (QC) is a web-based QA testing and management tool. It is a 
product from HP when they took over Mercury Interactive last year.

The front-end of the application is composed of COM components that plug into 
the web browser. Quality Center provides a customization capability (called 
workflow) which allow the administrator to modify the default behavior. This 
workflow is driven by VBScript functions that are called whenever a particular 
event occurs on the client front-end.

In order to optimize the interaction speed of the application, a cache folder 
is created on the client machine. By default, this folder is located at 
%tmp%/TD_80. Whenever a user connects to a Quality Center project, 2 folders 
are created within the cache folder. One of these folders contain a copy of the 
workflow scripts used to customize the application. Indeed, those files are 
required on the client machine because the workflow is execute on the client, 
not on the server.

There exists 1 VBScript workflow file per feature. Those are:
* Login/Logout (common.tds)
* Defects module (defects.tds)
* Manual Test Execution (manrun.tds)
* Test Requirements module (req.tds)
* Test Lab module (testlab.tds)
* Test Plan module (testplan.tds)

The customization feature of Quality Center is often used for:
* Controlling password compliance (no blank password, more than 8 letters, 
etc.)
* Chained lists (when a value is selected in a field, another field gets 
updated with a list relevant to that value)
* Automatic updates to some QC components (Test, Test Set, Defect objects, 
hidden fields)
* Hidding information depending on the user's group (used when a project is 
shared with different vendors)
* Others

The workflow is often driven by using the OTA (Open Test Architecture), the 
Quality Center API. This API allows the manipulation of any QC object (e.g. 
Subject folder, Test/Defect objects, Fields, etc.). It also allows the direct 
manipulation of the database used by Quality Center.

Issue
---

When a user connects to Quality Center, the cache folder is automatically 
updated with the latest VBScript workflow files. Those files are then read by 
the QC front-end only once for the whole session. They are then used by the 
application whenever the associated events are raised.

There are 2 main points that make this workflow highly vulnerable:
1. Those files are written in plain text;
2. Marking those files as read-only (through the file properties) will 
prevent Quality Center from overwriting them.

If a user modifies this file and then mark it as read-only, he can execute 
arbitrary code. As the OTA API allows access to the database, he can also 
modify the data stored in the database as follows:
* Quality Center 9.2 (Unconfirmed)
  - Severity High: user has higher capability than defined by their 
profile
* Quality Center 9.0 Patch  17
  - Severity Highly Critical: a user (even with a Viewer profile) can 
amend the data rendering it useless. He will also have higher capability than 
defined by their profile
* Quality Center 8.2 / 8.0 (Unconfirmed)
  - Severity Highly Critical: a user (even with a Viewer profile) can 
amend the data rendering it useless. He will also have higher capability than 
defined by their profile
* TestDirector (Any Version)
  - TestDirector is the former name of Quality Center
  - Potentially the same issues as for Quality Center 9.0 Patch  17

Please note that HP has released a patch that fixes this issue, please contact 
HP support for further details.

Example


This really short example shows how a user can simply change the content of all 
the defects to some meaningless values:

Sub Defects_Bug_MoveTo
Set objCommand = TDConnection.Command
objCommand.CommandText = UPDATE BUG SET BG_SUMMARY='Useless', 
BG_DESCRIPTION='Useless' 
objCommand.Execute
End Sub

Other Information
-

Discovered By: Exposit Limited
Internet:http://www.exposit.co.uk

Exposit Limited is a functional testing consultancy company specialized in HP 
(formely Mercury) Testing Tools.