Source: cve@mitre.org
/usr/sbin/Mail on SGI IRIX 3.3 and 3.3.1 does not properly set the group ID to the group ID of the user who started Mail, which allows local users to read the mail of other users.
Local privilege escalation is possible on SGI IRIX 3.3 and 3.3.1 due to a flaw in the Mail program. This vulnerability allows any local user to read the mailboxes of other users by exploiting an improper group ID setting, leading to unauthorized information disclosure.
Step 1: User Login: A local user logs into the vulnerable SGI IRIX system.
Step 2: Mail Execution: The user executes the /usr/sbin/Mail program.
Step 3: Group ID Flaw: The Mail program fails to correctly set its effective group ID to the user's group ID.
Step 4: File Access: Because of the incorrect group ID, Mail accesses mail files with the wrong permissions.
Step 5: Mailbox Reading: The user can read the mailboxes of other users, as the mail files are accessible due to the incorrect group ID.
The vulnerability stems from a failure in the Mail program to correctly set the effective group ID to the group ID of the user launching the application. Specifically, when Mail is executed, it should set its effective group ID to the user's group ID to ensure proper file permissions for accessing mail files. However, in IRIX 3.3 and 3.3.1, this step is omitted or implemented incorrectly. This means that Mail runs with the default group ID, which may grant access to files (including mail files) that should be restricted. The root cause is a missing or incorrect call to setegid() or a similar function to set the effective group ID. This allows a user to read other users' mailboxes because the mail files are likely group-readable, and Mail runs with a group ID that grants access.
This vulnerability is not associated with any specific APTs or malware campaigns due to its age and the limited use of the affected operating system. It is not listed in the CISA KEV catalog.
Review system logs for unusual access patterns to mail files (e.g., access by users other than the owner).
Monitor file access events using tools like auditd (if available) to detect unauthorized access to mail files.
Analyze process execution logs to identify instances where /usr/sbin/Mail is run and its effective group ID.
Check file permissions of mail files to ensure they are not group-readable.
Upgrade to a patched version of IRIX (if available).
If upgrading is not possible, restrict access to the /usr/sbin/Mail program using file permissions (e.g., only allow the root user to execute it).
Ensure that mail files are not group-readable. Set appropriate file permissions (e.g., owner-only read/write) for mail files.
Implement a security audit to review file permissions and user access rights.
Consider using a different mail client or service if possible.