bugtraq - Sun IDM Arbitrary Commands Execution Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4A098A48.1000301@scanit.be>
Date: Tue, 12 May 2009 16:40:08 +0200
From: "abb@...nit.be" <abb@...nit.be>
To: bugtraq@...urityfocus.com
Subject: Sun IDM Arbitrary Commands Execution Vulnerability

1) Summary

Affected Software: Sun IDM 7.1, 8.0
Vendor URL: http://www.sun.com/
Severity: Medium

2) Description

Sun Identity Manager facilitates centralized identity provisioning for
variety of application and platforms. Its web interface allows end users
to request password change. To handle such requests the system has to
manipulate account databases on the target resources. In the case of
*NIX-based systems the management server remotely logs in to a target
server and issues a series of shell command, using send-expect technique.

The system allows users to submit passwords containing control
characters including new line (ASCII 0x0A). The implementation of
send-expect mechanism fails to handle such  passwords correctly. This
flaw allows an unprivileged Sun IDM user to execute an arbitrary UNIX
shell command by requesting a password to be changed to a specially
crafted value. The injected command will be executed with root
privileges on all UNIX systems the user is provisioned on.

3) Details

The attack is enabled by two factors:

    1. New line character (ASCII 0x0A) is allowed in user passwords
    2. *NIX connectors utilize send-expect technique to interact
	with 'passwd' program, but fails to handle passwords
	containing new line characters.

In the process of changing the user password to a value containing a
newline the interaction between the IDM connector and UNIX shell goes
out of sync and the password gets executed by UNIX shell running as root.

To reproduce, request a password change for a user provisioned on some
Solaris server. The password has to consist of a UNIX shell command to
be executed repeated twice and separated by the new line character. One
way of doing it is to use an intercepting web proxy (such as Webscarab)
to modify HTTP message carrying the password change request. For
example, to inject 'id > /x' command, the modified request will look as
following:

    POST /idm/user/changePassword.jsp?lang=en&cntry=US HTTP/1.1
    id=***&command=Save&activeControl=&resourceAccounts.selectAll=true&

resourceAccounts.password=id>/x%0aid>/x&resourceAccounts.confirmPassword=id>/x%0aid>/x

In the request above the values of resourceAccounts.password and
resourceAccounts.confirmPassword parameters contain %0a, which is
URL-encoding for the new line character. After the request is submitted,
/x file will appear on resources the user is provisioned at:

    # ls -l /x
    -rw-r--r-- 1 root root 24 Dec 22 15:52 /x
    # cat /x
    uid=0(root) gid=0(root)

4) Solution

This vulnerability is addressed by security patches released by the
vendor. Sun Alert document #253267
(http://sunsolve.sun.com/search/document.do?assetkey=1-26-253267-)
contains information about suitable patches.

5) Workaround

The password policy can be used to prohibit new line characters in
passwords. This can be done by editing the password policy object
through the debugging interface of IDM, the relevant portion of the
object should look as follows:

    <Attribute name='Must Not Contain Words'>
    <List>
    <String>&#xA;</String>
    </List>
    </Attribute>

The workaround is somewhat fragile, it must be re-applied each time
after the password policy gets edited via GUI, because GUI drops the new
line character from the rule.

6) Time Table

    2008/12/24 The vendor was informed
    2009/01/14 The vendor has confirmed the problem
    2009/03/23 Sun Security Alert #253267 was published
    2009/05/12 Scanit Advisory was published

7) Additional Information

The original advisory can be found here:
http://www.scanit.be/advisory-2005-05-12.html

8) About Scanit

Scanit is a security company located in Brussels, Belgium. We specialize
in security assessments, offering services such as penetration tests,
application source code reviews, and risk assessments. More information
can be found at http://www.scanit.be/

-- 
Alexandre Bezroutchko