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