Multiple Vendor UNIX adduser/useradd Vulnerability
BID:1950
Info
Multiple Vendor UNIX adduser/useradd Vulnerability
| Bugtraq ID: | 1950 |
| Class: | Design Error |
| CVE: | |
| Remote: | No |
| Local: | Yes |
| Published: | Nov 10 2000 12:00AM |
| Updated: | Nov 10 2000 12:00AM |
| Credit: | This vulnerability was first announced by Michal Zalewski <[email protected]> on November 10, 2000. |
| Vulnerable: |
Redhat Linux 6.1 sparc Redhat Linux 6.1 i386 Redhat Linux 6.1 alpha Redhat Linux 6.0 sparc Redhat Linux 6.0 alpha Redhat Linux 6.0 Redhat Linux 5.2 sparc Redhat Linux 5.2 i386 Redhat Linux 5.2 alpha OpenBSD OpenBSD 2.8 OpenBSD OpenBSD 2.7 OpenBSD OpenBSD 2.6 |
| Not Vulnerable: |
Debian Linux 2.2 |
Discussion
Multiple Vendor UNIX adduser/useradd Vulnerability
In some UNIX environments, there may exist a problem which could allow a user to gain elevated priviledges. This problem manifests in UNIX systems with userless groups.
The problem exists in UNIX User Management Utilities driven by a secondary interface that operates with priviledge sufficient to add users. In UNIX implementations that add users with groups of their own, it is possible for a poorly designed secondary interface to use a program, such as useradd or adduser, and place the user in a elevated priviledge group that doesn't have a user in the passwd file.
Such a scenario could include a web management interface that allows users to add their own accounts, and provide the user intentional access via shell or unintentional access by another means such as web or ftp. The user would then have to select a username for which a corresponding group exists (but no user), such as 'kmem'. When useradd or adduser adds the user, they will be assigned the groupid for the corresponding group if it exists (such as kmem for example). This is only possible if user 'k mem' does not exist beforehand and the adduser/useradd tools set groupid to that of the group with the same name of the new user.
This problem could lead to an elevation of priviledges by a malicious user.
In some UNIX environments, there may exist a problem which could allow a user to gain elevated priviledges. This problem manifests in UNIX systems with userless groups.
The problem exists in UNIX User Management Utilities driven by a secondary interface that operates with priviledge sufficient to add users. In UNIX implementations that add users with groups of their own, it is possible for a poorly designed secondary interface to use a program, such as useradd or adduser, and place the user in a elevated priviledge group that doesn't have a user in the passwd file.
Such a scenario could include a web management interface that allows users to add their own accounts, and provide the user intentional access via shell or unintentional access by another means such as web or ftp. The user would then have to select a username for which a corresponding group exists (but no user), such as 'kmem'. When useradd or adduser adds the user, they will be assigned the groupid for the corresponding group if it exists (such as kmem for example). This is only possible if user 'k mem' does not exist beforehand and the adduser/useradd tools set groupid to that of the group with the same name of the new user.
This problem could lead to an elevation of priviledges by a malicious user.
Exploit / POC
Multiple Vendor UNIX adduser/useradd Vulnerability
Currently the SecurityFocus staff are not aware of any exploits for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
Currently the SecurityFocus staff are not aware of any exploits for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
Solution / Fix
Multiple Vendor UNIX adduser/useradd Vulnerability
Solution:
Currently the SecurityFocus staff are not aware of any vendor supplied patches for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
Solution:
Currently the SecurityFocus staff are not aware of any vendor supplied patches for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
References
Multiple Vendor UNIX adduser/useradd Vulnerability
References:
References: