COMMAND

    UID/GID

SYSTEMS AFFECTED

    Red Hat 4.1, FreeBSD 2.2

PROBLEM

    The following "feature" is  ideal for backdoors on  Linux systems.
    It was found by David Phillips.   If you try to make a user  entry
    in  the  /etc/passwd  file  by  placing  a  #  in front of the UID
    something wierd  happens.   If you  make su  you'll be rewarded by
    being  dumped  to  UID  0.   It  didn't  recognize  the  UID so it
    defaulted to 0.

    It seems ideal  for a hard  to find, backdoor  but given that  you
    must be  root to  write to  the passwd  file, this  can be used to
    hide yourself for little.

    Tests showed that this problem  tgat trying to rlogin, rsh,  rexec
    or  telnet  will  fail  with  an  authentication failure. But, su,
    ftp, ssh  and console  login all  will succeed  and give  UID 0. A
    small stumbling  block, but  still useful  for a  backdoor.   Same
    works for GID.

    Jim Trocki  pointed out  that the  problem is  that when  libc was
    built, NO_SKIP_BAD was not defined. It appears that NO_SKIP_BAD is
    *not* the default value, so it's easily overlooked.

    David Phillips  reported same  behaviour Same  behavior on FreeBSD
    (2.2).

SOLUTION

    Well, do not put hashes in your passwd and keep watching for  them
    if  you  run  RedHat  box.   Joke.   Here's  the code snippet from
    pwd/pwdread.c of libc-5.3.12 that does the sanity checking:

      info->p.pw_uid = (uid_t) strtol (end + 1, &end, 10);
      if (*end != ':')
    #ifdef NO_SKIP_BAD
        return ( is_nis_entry ? &info->p : NULL );
    #else
        if (is_nis_entry)
          return &info->p;
        else
          goto restart;
    #endif

    strtol(3)  returns  a  NULL  if  it finds a non-decimal character,
    hence struct passwd gets a zero in the pw_uid field.