Note: This is an archival copy of Security Sun Alert 200139 as previously published on http://sunsolve.sun.com.
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1000101.1.
Article ID : 1000101.1
Article Type : Sun Alerts (SURE)
Last reviewed : 2003-07-20
Audience : PUBLIC
Copyright Notice: Copyright © 2010, Oracle Corporation and/or its affiliates.

Automountd(1M) May Stop and/or OpenSSH May Experience Authentication Issues



Category
Security

Category
Availability

Release Phase
Resolved

Product
Solaris 8 Operating System

Bug Id
4847047

Date of Resolved Release
21-JUL-2003

Impact

Installation of Solaris 8 patch 108993-14 through 108993-19 on the SPARC platform or Solaris 8 Patch 108994-14 through 108994-19 on the x86 platform, may result in the following issues:

1. A local unprivileged user may be able to create a denial of service for automountd(1M) by crashing this process. This would affect all applications that are dependent on file systems which are automatically mounted through the automounter.

2. Authentication through OpenSSH may fail on a native LDAP (ldap(1)) client system that have been configured for the "tls:simple" authentication method.


Contributing Factors

This issue can occur in the following releases:

SPARC Platform

  • Solaris 8 with patch 108993-14 through 108993-19 and without patch 108993-20

x86 Platform

  • Solaris 8 with patch 108994-14 through 108994-19 and without patch 108993-20

Note: Solaris 2.6, Solaris 7, and Solaris 9 are not affected by this issue.


Symptoms

One possible indication that automountd(1M) is affected by this issue is the absence of the "automountd" process.

    % pgrep automountd

Nothing is returned if the process is not running.

The automountd(1M) process core dumps. Using pstack(1) on the core file may show a thread with a stack similar to the following:

    ----------------- lwp# 15 / thread# 149 --------------------
fef49ec0 ldap_ld_free (81b00, 0, 5f598, feca7568, 1, 81b00) + 18
feca7578 ldap_open (5f150, 0, ff13fd60, 33a38, fe7046c9, fe7046ca) + bc
fecd4840 __0oHLDAPDUActRi (62460, fe705014, fecf78fc, fecf53e0, fecf7925 ...
feccf5e8 __0oLX500ContextctRC6LFN_ref_addrRC6GFN_refUiRi (66800, 62460 ...
feccf314 ASx500 (66800, 0, 0, 62640, 64674, 89d18) + 34
fee866b4 __0fGFN_ctxIfrom_refRC6GFN_refUiR6JFN_statusT (89d18, 0, 69e28 ...
fee84c7c fn_ctx_handle_from_ref (89d18, 0, 89d18, 668f0, 62640, 0) + 14
feeb3f34 ???????? (89d18, 0, 1, 62640, feec6000, 2f2e2e2e)
feeb3538 getmapkeys_fn (64530, fe705b04, 668f0, 62640, 89dd8, feec6000) + 140
000237cc getmapkeys (0, 0, fe705af8, fe705afc, fe705a80, fe705a7c) + 138
00021fdc do_readdir (31f88, fe705bc8, 33da8, fe705be0, 7e690, fe705be0) + 170
00015a10 ???????? (30800, fe705bc8, 7e690, fe705bc8, fe705be0, fe705be1)
00015940 ???????? (15654, 159d0, 15a40, 21ad8, 21dfc, 34988)
ff2881ec _svc_prog_dispatch (67960, 686e8, 34988, ff290860, 4f6a8, 4f668) + ...
ff1db728 _thread_start (0, 0, 0, 0, 0, 0) + 40

If a user whose account information is stored in LDAP tries to login via OpenSSH to a native LDAP client system configured with the "tls:simple" authentication method, the login will hang. A truss shows the following sequence:

    ...
222/1:          17.7946                                 -> sldaputil
:alg_fips186_1_x3_1(0x145198, 0x0, 0x0, 0x0)
222/1:          17.7952                                 -> sldaput
il:PORT_SetError(0xffffe005, 0x0, 0x0, 0x0)
222/1:          17.7958                                 -> sldaput
il:PR_SetError(0xffffe005, 0x0, 0x0, 0x0)
222/1:          17.7965                                 -> sldap
util:PR_GetCurrentThread(0x0, 0x0, 0x0, 0x0)
222/1:          17.7971                                 <- sldap
util:PR_GetCurrentThread() = 0x14fd90
222/1:          17.7976                                 <- sldaput
il:PORT_SetError() = -8187
222/1:          17.7984                                 <- sldaputil
:alg_fips186_1_x3_1() = -1

Note: The authentication of OpenSSH only occurs if the authentication method is set to "tls:simple". Refer to the NS_LDAP_AUTH line in the "ldapclient -l" output to verify if using "tls:simple" for authentication.


Workaround

To workaround the automountd issue, apply one of the following suggestions:

  • Remove the "/xfn" entry from the "auto_master" mapfile (either in files or NIS, NIS+, or LDAP).
  • Backout patch 108993-14 through 108993-19 on the SPARC platform or patch 108994-14 through 108994-19 on the x86 platform.
  • Create a simple script to check if "automountd" is running, and restart "automountd" as needed.

To workaround the OpenSSH issue, apply one of the following suggestions:

  • Do not setup native LDAP for transport layer security (tls). Use other supported authentication methods.
  • Backout patch 108993-14 through 108993-19 on the SPARC platform or patch 108994-14 through 108994-19 on the x86 platform.

Resolution

This issue is addressed in the following releases:

SPARC Platform

  • Solaris 8 with patch 108993-20 or later

x86 Platform

  • Solaris 8 with patch 108994-20 or later


Modification History
Date: 30-JUL-2003
  • Updated Synopsis


References

108994-20
108993-20




Attachments
This solution has no attachment