Bug 11107 - ksu can lock up 2.3.99-pre5 kernel (can be done by regular users)
ksu can lock up 2.3.99-pre5 kernel (can be done by regular users)
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.2
All Linux
high Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-04-28 17:31 EDT by SB
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-14 19:14:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description SB 2000-04-28 17:31:50 EDT
A regular user can lock up a system by executing ksu(suid root) with an
argv[0] replaced with alot of data.  I tried it with 100k and you can see
in the example below what happened. (FYI ksu as in the kerberos su, to
avoid any confusion)

For example:
(for the example I will abbreviate the 100000 A's in the output as <CHUNK>)

bash-2.04$ doexec ksu `perl -e'print "A" x 100000;'`
WARNING: Your password may be exposed if you enter it here and are logged
         in remotely using an unsecure (non-encrypted) channel.
Kerberos password for root@EXAMPLE.COM: <hit Ctrl-C> <CHUNK>: Password read
interrupted while reading password for 'root@EXAMPLE.COM'

Authentication failed.
<CHUNK>[1124]: '<CHUNK> root' authentication failed for www on /dev/pts/2
<system is now locked up completely>

Nothing can be done.  The system is completely locked up after about 10-15
seconds and after that period of time the system will not respond to
anything.  I've been trying to track it down and I think this is where it
is freezing as far as program execution goes:
main.c:
                if (auth_val ==FALSE){
                        fprintf(stderr, "Authentication failed.\n");
                         syslog(LOG_WARNING,
                                "'%s %s' authentication failed for %s%s",
                                prog_name,target_user,source_user,ontty());
                        sweep_up(ksu_context, use_source_cache, cc_target);
                        exit(1);
                }

Since fprintf and syslog are being executed and exit(1) never seems to
happen the problem must be somewhere in sweep_up function, unless syslog
never exits which is unlikely.  The part of the sweep_up function below is
as far as I can guess is triggering the problem, though I'm not sure where
exactly.  The thing that stands out to me is the fact the com_err never
gets displayed.
main.c:
if (! use_source_cache){
                cc_name = krb5_cc_get_name(context, cc);
                if ( ! stat(cc_name, &st_temp)){
                        if ((retval = krb5_cc_destroy(context, cc))){
                                com_err(prog_name, retval,
                                        "while destroying cache");
                        }
                }
        }
}

This was done using latest kerberos packages from rawhide and 2.3.99-pre5
kernel.

-Stan Bubrouski
Comment 1 SB 2000-04-28 17:44:59 EDT
I was just looking at my logs and there is no log of when this occured, nothing
was logged when it happened...not even ksu's syslog call got logged even thought
it was displayed which may suggest the problem is triggered in syslog, however I
still think it is a kernel problem.
Comment 2 SB 2000-05-14 19:14:59 EDT
Ok the redhat version of kerberos 5 isn't the only one to trigger this, as I
downloaded beta's for kerberos 1.2 beta 1 and tried it again using ksu and got
this:

kmalloc: Size (140084) too large
kmalloc: Size (140084) too large
kmalloc: Size (140084) too large
...continues FOREVER!!!

no keybaord intervention like ctrl-c or z or anything would interrupt it and
console switching is not functional either, the only thing that can be done (AND
THANK GOD) is using Sys Rq key combos to sync drives, unmount em, and reboot.

Is this a kernel problem?

-Stan Bubrouski
Comment 3 Alan Cox 2000-08-08 17:11:37 EDT
Yes its a kernel issue but report it to linux-kernel@vger.rutgers.edu as its a
mainstream kernel issue not a Red Hat one

Note You need to log in before you can comment on or make changes to this bug.