Re: [Full-Disclosure] iDEFENSE Security Advisory 09.16.03: Remote Root Exploitation of Default Solaris sadmind Setting

From: Person (devon_at_lithiumnode.com)
Date: 09/16/03

  • Next message: Ron DuFresne: "Re: [Full-Disclosure] new ssh exploit?" 
    To: full-disclosure@lists.netsys.com
Date: Tue, 16 Sep 2003 08:29:09 -0700 (PDT)

    Hasn't there always been a warning in the sadmind man page about security
    levels less than 3? I'm not sure this "exploit" is newsworthy.

    [d]

    On Tue, 16 Sep 2003, iDEFENSE Labs wrote:

    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > iDEFENSE Security Advisory 09.16.03:
    > http://www.idefense.com/advisory/09.16.03.txt
    > Remote Root Exploitation of Default Solaris sadmind Setting
    > September 16, 2003
    >
    > I. BACKGROUND
    >
    > Solstice AdminSuite is a set of tools packaged by Sun Microsystems Inc.
    > in its Solaris operating system to help administrators manage systems
    > remotely, centralize configuration information and monitor software
    > usage. The sadmind daemon is used by Solstice AdminSuite applications
    > to perform these distributed system administration operations. The
    > sadmind daemon is typically installed and enabled in a default Solaris
    > installation.
    >
    > II. DESCRIPTION
    >
    > An exploit has surfaced that allows remote attackers to execute
    > arbitrary commands with super-user privileges against Solaris hosts
    > running the default RPC authentication scheme in Solstice AdminSuite.
    > This weakness is documented to some extent in Sun documentation,
    > http://docs.sun.com/db/doc/816-0211/6m6nc676b?a=view .
    >
    > By sending a sequence of specially crafted Remote Procedure Call (RPC)
    > requests to the sadmind daemon, an attacker can exploit this
    > vulnerability to gain unauthorized root access to a vulnerable system.
    > The sadmind daemon defaults to weak authentication (AUTH_SYS), making
    > it possible for a remote attacker to send a sequence of specially
    > crafted RPC packets to forge the client identity.
    >
    > After the identity has been successfully forged, the attacker can
    > invoke a feature within the daemon itself to execute a shell as root
    > or, depending on the forged credential, any other valid user of the
    > system. The daemon will execute the program of the attacker’s choice;
    > for example, spawning a reverse-network shell back to the attacker for
    > input/output control. Under certain circumstances, a reverse-network
    > shell could allow for the attacker to bypass firewalls and/or filters.
    >
    > III. ANALYSIS
    >
    > Because the nature of the weakness exists on the application level,
    > successful exploitation does not require the use of machine-specific
    > code, nor does it require any previous knowledge of the target's
    > architecture. Therefore, any local or remote attacker could execute
    > commands as root on a vulnerable system running the sadmind service. By
    > default, sadmind is installed and started at system boot time on most
    > default and fully patched installations of Solaris. While many other
    > vendors rely on SUNRPC related routines from Sun, this design issue is
    > confined to Sun's sadmind authentication implementation in Solaris.
    > The most inherent threat is if this exploit becomes packaged into a
    > cross-platform worm were it to become publicly available.
    >
    > IV. DETECTION
    >
    > An exploit has been obtained and demonstrated in real-world conditions
    > on systems running Solaris or Trusted Solaris operating systems running
    > sadmind. Default installations of SunOS 5.3 thru 5.9 (Solaris 2.x, 7,
    > 8, 9) on both the SPARC and _x86 platforms are susceptible. In
    > addition, versions 7 and 8 of Trusted Solaris on both the SPARC and
    > _x86 platforms are susceptible to exploitation. Exploitation occurs
    > through an initial request through UDP or TCP port 111 (sunrpc).
    >
    > V. WORKAROUNDS
    >
    > For Solaris hosts that do not require the Solstice AdminSuite related
    > services, disable the sadmind service by commenting out the appropriate
    > line in /etc/inetd.conf. Make sure to restart inetd after changing
    > this file (e.g. pkill -HUP inetd).
    >
    > For networks, ensure proper ingress filters are in place on the
    > Internet router and firewall, especially on TCP and UDP port 111.
    >
    > For Solaris hosts that require the Solstice AdminSuite to be running,
    > the authentication security settings of sadmind should be increased to
    > STRONG (AUTH_DES) — this is not the default setting. This setting also
    > requires the creation of NIS or NIS+ DES keys to have been created for
    > each Solaris user and each host.
    >
    > In order to upgrade the authentication setting, the sadmind line in
    > /etc/inetd.conf should be changed to look like the following:
    >
    > 100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2
    >
    > Sun also recommends using the Solaris Security Toolkit (JASS) to harden
    > a Solaris system, http://wwws.sun.com/software/security/jass/ .
    >
    > VI. VENDOR RESPONSE
    >
    > Sun does not plan on releasing a patch for this issue. Because a
    > working exploit now exists for this issue, Sun Microsystems Inc. is
    > issuing Alert 56740 to ensure administrators have proactively applied
    > the proper workarounds in the event this exploit or one like it becomes
    > publicly available. Sun's alert is available at
    > http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F56740 .
    >
    > VII. CVE INFORMATION
    >
    > The Mitre Corp.'s Common Vulnerabilities and Exposures (CVE) Project
    > has assigned CAN-2003-0722 to this issue.
    >
    > VIII. DISCLOSURE TIMELINE
    >
    > 26 AUG 2003 Exploit acquired by iDEFENSE
    > 26 AUG 2003 Sun notified (security-alert@sun.com)
    > 27 AUG 2003 Followup status request via phone
    > 27 AUG 2003 Response from Derrick Scholl, Sun Security
    > Coordination Team
    > 02 SEP 2003 iDEFENSE clients notified
    > 16 SEP 2003 Coordinated Public Disclosure
    >
    > IX. CREDIT
    >
    > Mark Zielinski (markzielinski@mailblocks.com) is credited with this
    > discovery.
    >
    >
    > Get paid for security research
    > http://www.idefense.com/contributor.html
    >
    > Subscribe to iDEFENSE Advisories:
    > send email to listserv@idefense.com, subject line: "subscribe"
    >
    >
    > About iDEFENSE:
    >
    > iDEFENSE is a global security intelligence company that proactively
    > monitors sources throughout the world - from technical
    > vulnerabilities and hacker profiling to the global spread of viruses
    > and other malicious code. Our security intelligence services provide
    > decision-makers, frontline security professionals and network
    > administrators with timely access to actionable intelligence
    > and decision support on cyber-related threats. For more information,
    > visit http://www.idefense.com .
    >
    >
    > -----BEGIN PGP SIGNATURE-----
    > Version: PGP 8.0.2
    >
    > iQA/AwUBP2cHuvrkky7kqW5PEQIywQCdE+ebPkgFjt9zL/uFig1zIWLM+JUAoLps
    > RC5Mn1cqMq4xqdONWy1EnbP0
    > =083t
    > -----END PGP SIGNATURE-----
    >
    > _______________________________________________
    > Full-Disclosure - We believe in it.
    > Charter: http://lists.netsys.com/full-disclosure-charter.html
    >

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

  • Next message: Ron DuFresne: "Re: [Full-Disclosure] new ssh exploit?"

    Relevant Pages