Note: This is an archival copy of Security Sun Alert 201374 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1001047.1.
Solaris 10 Operating System
Date of Resolved Release
A security vulnerability in the Solaris Auditing (BSM) included with Solaris 10 may allow a local unprivileged user to cause a system panic on hosts which are configured to audit networking events. This would result in a Denial of Service (DoS) to the system as a whole.
This issue can occur in the following releases:
Note: Solaris 8 and Solaris 9 are not impacted by this issue.
This issue only affects hosts which have Solaris Auditing enabled (see bsmconv(1M)) and are configured to audit networking events (those included in the "nt" auditing class).
To determine if Solaris Auditing is enabled on a system, a command such as the following can be used to search the "/etc/system" file for a reference to the "c2audit" kernel module:
$ grep c2audit /etc/system set c2audit:audit_load = 1
To determine which audit classes have been configured on the system, consult the audit_control(4) and audit_user(4) files. Note also that it is possible to enable audit classes for individual processes using the auditconfig(1M) command.
A command such as the following can be run as root to determine which classes are enabled for a specific process:
# auditconfig -getpinfo <process id> | grep 'mask' process preselection mask = lo,nt(0x1100,0x1100)
This command should be applied to all processes, or at least any processes which may have had their audit preselection mask modified by a system administrator.
If this issue has been exploited to cause a Denial of Service (DoS), the system will panic in the au_getsonode() function.
The following is an example of a stack trace which may result from this issue:
au_getsonode+0x20(3, d07c3eb0, 0) auf_bind+0x33(d0c1e198, 0, d07c3f28) audit_finish+0xdc(180, e8, 0, d07c3f28) [...]
To work around this issue, auditing of the "nt" class can be disabled. This can be done by modifying the audit_control(4) and audit_user(4) files and then either rebooting the system or modifying the audit preselection mask of running processes on the system using auditconfig(1M) with the "-setpmask" argument.
Note: Applying this workaround will reduce the thoroughness of the auditing data produced on the host as network events will no longer be audited.
This issue is addressed in the following releases:
This solution has no attachment