MOO-cows Mailing List Archive

[Prev][Next][Index][Thread]

[SERVER, SECURITY] bug in set_task_perms() ?



Some time ago, Rui pointed out that the current definition of
set_task_perms() may lead to a security hole.
The problem is that wizperms can set_task_perms() to an invalid object.
Some verbs rely on testing whether valid(caller_perms()), as a general test
for 'am I being called from command line, or from another verb?', just
because this is cheaper than using callers(). But setting task perms to an
invalid may fool this.
I suggest that bf_set_task_perms be modified to return E_INVARG if the
wizard attempts to set_task_perms() to an invalid object. The modification
is very simple. In execute.c, modify:

static package
bf_set_task_perms(Var arglist, Byte next, void *vdata, Objid progr)
{ /* (player) */
    /* warning!!  modifies top activation */
    Objid oid = arglist.v.list[1].v.obj;

    free_var(arglist);

    if (progr != oid && !is_wizard(progr))
        return make_error_pack(E_PERM);

    if (!valid(oid))                          |  Just add these
        return make_error_pack(E_INVARG);     |  two lines.

    RUN_ACTIV.progr = oid;
    return no_var_pack();
}


This modification shouldn't break anything in LambdaCore.
Is anyone using this 'feature' of setting task perms to an invalid for
anything useful?

-------------------------------------------------------------
Gustavo Glusman               Founder/administrator of BioMOO
-- Gustavo@bioinformatics.weizmann.ac.il
-- http://bioinformatics.weizmann.ac.il:70/0h/Gustavo/Glusman
-- BioMOO: telnet bioinformatics.weizmann.ac.il 8888
           WWW:   http://bioinfo.weizmann.ac.il:8888




Follow-Ups:

Home | Subject Index | Thread Index