[19224] in bugtraq
Re: vixie cron possible local root compromise
daemon@ATHENA.MIT.EDU (Settle, Sean)
Thu Feb 15 14:51:13 2001
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <158CB85CAF43D311B0710090274F07FE0243462E@ntex5npc.alliant.com>
Date: Wed, 14 Feb 2001 17:42:36 -0700
Reply-To: "Settle, Sean" <SeanSettle@ALLIANTFS.COM>
From: "Settle, Sean" <SeanSettle@ALLIANTFS.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
% uname -smr; man passwd
FreeBSD 4.2-RELEASE i386
RESTRICTIONS
username
Login name. May contain only lowercase characters or digits.
Maximum length is 16 characters (see setlogin(2) BUGS section).
The reasons for this limit are "Historical". Given that people
have traditionally wanted to break this limit for aesthetic
rea-
sons, it's never been of great importance to break such a basic
fundamental parameter in UNIX. You can change UT_NAMESIZE in
/usr/include/utmp.h and recompile the world; people have done
this and it works, but you will have problems with any precom-
piled programs, or source that assumes the 8-character name
limit
and NIS. The NIS protocol mandates an 8-character username.
If
you need a longer login name for e-mail addresses, you can
define
an alias in /etc/mail/aliases.
On HP-UX I couldn't find this information in passwd or useradd. I took a
peek at 'man utmp' and found this, but it's probably not the final word on
the subject:
struct utmp {
char ut_user[8]; /* User login name */
char ut_id[4]; /* /etc/inittab id(usually
line#)*/
char ut_line[12] /* device name (console, lnxx)
*/
pid_t ut_pid; /* process id */
Sean Settle
"To sin by silence when we should protest makes cowards out of men" - Ella
Wheeler Wilcox
X Network Services Q NPC X
Phoenix, AZ
SMTP: seansettle@alliantfs.com
-----Original Message-----
From: Valdis Kletnieks [mailto:Valdis.Kletnieks@VT.EDU]
Sent: Wednesday, February 14, 2001 9:34 AM
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: Re: vixie cron possible local root compromise
On Tue, 13 Feb 2001 22:27:14 -0200, "Rodrigo Barbosa (aka morcego)"
<rodrigob@CONECTIVA.COM.BR> said:
> #include <wtmpx.h>
>
> main () {
> printf("%d\n",__UT_NAMESIZE);
> }
Of course, what's important isn't what wtmpx.h defines it as, but what pwd.h
has to say about it. If getpwent() won't handle it, your wtmp format
doesn't
matter...
Note also that some systems have utmpx.h not wtmpx.h
> If anyone can find any system that reports less then 32, it will be an
exce=
> ption
> of the rule. Of course I mean current systems. libc5 systems, AIX 3.2 and
o=
> ld
> systems like that will probably return 16 or even 8.
AIX 4.3.3 and AIX 5.0 both limit it to 8 in utmpx.h
Solaris 5.7 has a 32-char limit in wtmp, but has this in 'man useradd':
The login field (login ) is a string no more than eight
bytes consisting of characters from the set of alphabetic
characters, numeric characters, period (.), underscore
(_), and hypen (-). The first character should be alpha-
betic and the field should contain at least one lower case
alphabetic character. A warning message will be written if
these restrictions are not met. A future Solaris release may
refuse to accept login fields that do not meet these
requirements. The login field must contain at least one
character and must not contain a colon (:) or a newline
(\n).
SGI 6.5.10f has a 32-char limit in utmpx.h, but 'man 4 passwd' says this:
name User's login name -- consists of alphanumeric characters and
must not be greater than eight characters long. It is
recommended that the login name consist of a leading lower
case
letter followed by a combination of digits and lower case
letters for greatest portability across multiple versions of
the UNIX operating system. This recommendation can be safely
ignored for users local to IRIX systems. The pwck(1M)
command
checks for the greatest possible portability on names, and
complains about user names that do not cause problems on
IRIX.
I'll let somebody else check Tru64 and HP/UX, I don't have access to them
at the moment.
Moral of the story: Not all the world is Linux, and some vendors care
more about backward and cross compatability than being the
latest-and-greatest.
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
