MOO-cows Mailing List Archive


[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;


    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
-- BioMOO: telnet 8888


Home | Subject Index | Thread Index