bugtraq - [NILESA-20050101]: Denial of Service vulnerability due to the mountd bug

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]

Date: 11 Jan 2005 15:14:46 -0000
From: Jonglim Yun <abc@...esoft.co.kr>
To: bugtraq@...urityfocus.com
Subject: [NILESA-20050101]: Denial of Service vulnerability due to the
    mountd bug




================================================================================

                        NileSOFT Security Advisory

--------------------------------------------------------------------------------

ID          : NILESA-20050101

Title       : Denial of Service vulnerability due to the mountd bug

Vendor  : SCO

URL       : www.sco.com

Product : UnixWare 7.1.4, 7.1.3, 7.1.1, 7.0.1 (and maybe other versions)

Severity: Moderate

Local     : Yes

Remote  : Yes

Date      : 11 Jan. 2005

CVE ID   : CAN-2004-1039

Author   : Yun Jonglim / NileSOFT. Ltd(www.nilesoft.co.kr)

================================================================================

 

1. SUMMARY

 

The NFS mountd service for UnixWare OS is generally run by

the RC script(/etc/rc3.d/S22nfs) on the NFS server system's boot run-level 3.

 

When the NFS mountd service is run by inetd, if a NFS mount related request is

received from the remote (or local) host, inetd will repeatedly create

the mountd process and as a result increasingly consume memory.

 

 

2. VULNERABILITY DESCRIPTION

 

The UnixWare operating system provides the NFS mountd service by

RC script(/etc/rc3.d/S22nfs) by default. However, as shown below, the service

is registered in the inetd.conf configuration file so that the inetd daemon can

also provide the service.

 

    # The mount server is usually started in /etc/rc.local only on machines that

    # are NFS servers.  It can be run by inetd as well.

    #

    #mountd/1        dgram   rpc/udp wait root /usr/sbin/in.tcpd       /usr/lib/nfs/mountd

    #mountd/1        dgram   rpc/udp wait root /usr/lib/nfs/mountd   mountd

 

By default, the mountd service registered in inetd.conf is commented out

(disabled) but the service can be enabled by removing the corresponding

'#' character and restarting inetd.(like below)

 

    # The mount server is usually started in /etc/rc.local only on machines that

    # are NFS servers.  It can be run by inetd as well.

    #

    mountd/1          dgram   rpc/udp wait root /usr/sbin/in.tcpd       /usr/lib/nfs/mountd

    #mountd/1        dgram   rpc/udp wait root /usr/lib/nfs/mountd   mountd

 

Like this, when the NFS mountd service is configured to be run by inetd,

the mountd process is run when the NFS mount service related request is received

from the remote (or local) host as shown below.

 

    showmount -e <affected_ip>

 

However, inetd does not created just one instance of the mountd process for the

request but repeatedly creates the process. This would cause the use of the

system memory to increase by time.

 

The same problem occurs regardless of which line or lines the # character is

removed. This problem has been identified for UnixWare versions 7.1.4 ~ 7.0.1

and other versions may also have this problem.

 

 

3. IMPACT

 

Due to the increase of the number of mountd processes, the system's memory

would become exhausted therefore resulting in system crash down.

 

 

4. REMEDY

 

Installation of the fixed binary packages will address this vulnerability.

Packages can be downloaded from below ftp site.

ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.1

 

SCO had released Security Advisory SCOSA-2005.1.

http://www.sco.com/support/security/index.html

 

 

5. DISCLOSURE TIMELINE

 

2004/10/22 Vulnerability found and analysis

2004/11/08 CVE notified and candidate number reservation request

2004/11/16 CVE candidate reserved

2004/11/16 Vender notified and initial response

2005/01/07 Vender Confirmed and patch prepared

2005/01/11 Advisory released

 

 

6. CVE INFORMATION

 

The Common Vulnerabilities and Exposures (CVE) project has assigned the

names CAN-2004-1039 to these issues. This is a candidate for inclusion

in the CVE list (http://cve.mitre.org), which standardizes names for

security problems.