Bug 11107 - ksu can lock up 2.3.99-pre5 kernel (can be done by regular users)
Summary: ksu can lock up 2.3.99-pre5 kernel (can be done by regular users)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2000-04-28 21:31 UTC by SB
Modified: 2008-05-01 15:37 UTC (History)
0 users

Clone Of:
Last Closed: 2000-05-14 23:14:22 UTC

Attachments (Terms of Use)

Description SB 2000-04-28 21:31:50 UTC
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:
                if (auth_val ==FALSE){
                        fprintf(stderr, "Authentication failed.\n");
                                "'%s %s' authentication failed for %s%s",
                        sweep_up(ksu_context, use_source_cache, cc_target);

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.
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

-Stan Bubrouski

Comment 1 SB 2000-04-28 21:44:59 UTC
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 23:14:59 UTC
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

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 21:11:37 UTC
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.