<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<link href="
http://vv.carleton.ca/%7Eneil/homepage.css" rel="stylesheet" type="text/css">
<title>Back to the Floor</title>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body>
<h1>Back to the Floor</h1>
Going "back to the floor" is a British term for sending a high-level
manager to work at the bottom of his/her organisation. It is a useful way of
getting out-of-touch management back in tune with the day to day
realities.
<P>
<a href="
http://www.moo.ca/dax">I</a> have been a wizard on
<a href="
http://www.moo.ca/">Moo Canada</a> for over six years. It is
time for me to go "back to the floor" and see the Moo from a non-wizard
perspective. I've anonymously created a character named "Brian".
Below is a log of the problems encountered during this experiment.
<P>
<hr>
<h3>The log:</h3>
<ol>
<li>Manta's hack to
<a href="
http://www.moo.ca/room%3Aannounce*_all_but">$room:announce*_all_but</a>
which is designed to fix broken notify verbs is itself broken. The
quotes around "notify" are missing on line 24. As a result of the error
trap, all one gets is "Pbbt".<P>
<li>There is no way for the Wizzen to monitor logged-in activity on the
web. @listen should notify listening Wizzen what URLs are being
submitted by that player. @lc should also record URLs.<P>
<li><a href="
http://www.moo.ca/13%3A@grep">$builder:@grep</a> needs the
following at the top (not a security hole, though):<br>
<tt>if (player != this)<br>
return $msg:mtell("huh");<br>
endif</tt><P>
<li>The same needs to be added to
<a href="
http://www.moo.ca/16%3A%40nec*ronomicon">$guardian:@necronomicon</a>
(the current check issues a message, but forgets the return).<P>
<li>Line 31 on
<a href="
http://www.moo.ca/exit%3Amove">$exit:move</a> blows up
before printing Manta's error message. The same error appears in
<a href="
http://www.moo.ca/vexit%3A%3Amove">$vexit::move</a> which
is a copy of $exit:move.<P>
<li>Lines 59, 78 and 98 in
<a href="
http://www.moo.ca/13%3A%40grep*%21%20%40egrep*%21">$builder:@grep!</a>
blow up for non-wizzen. <TT>s /0, caller_perms()//1-$</TT><P>
<li>There are some fishy properties and files on
<a href="
http://www.moo.ca/no_one.%21">$no_one</a>. I can't see how they
were created, but they should probably be removed. The "gammy" property
has been there for over two years, but the files are much more recent.
There is a hole here somewhere, but I can't see it.<P>
<li><a href="
http://www.moo.ca/builder%3A%40dump%202dump">$builder:@dump</a>
has a broken attempt to comply with Manta's -o verbs on line 119.
Because this verb is -d, nobody has noticed that it is failing. A @grep
shows that this error has spread to
<a href="
http://www.moo.ca/builder%3A%40rawdump">$builder:@rawdump</a>
(line 102) and to
<a href="
http://www.moo.ca/dump%3Ado_www_dump">$dump:do_www_dump</a>
(line 118) due to verb copying.<P>
<li>Guardians can see failed web passwords by sniffing argstr or dobjstr
in the cracker messages from
<a href="
http://www.moo.ca/webber%3AAuthorization%3A%20Proxy-Authorization%3A">$webber:Authorization:</a>.
Although I am not concerned about guardians cracking into accounts, I am
concerned that someone listening/spying on a guardian would gain access
to this.<P>
<li>The above verb should either have a return or an else/endif after
the boot_player for newts. As it stands, a newt can login, though they
get disconnected very quickly. Race condition.<P>
<li>Manta has created lots of blank verbs around the core. Some of these
are clearly intentional in that they imply "return 0;". Some of these
are clearly abandoned verbs that never made it to an editor. The
problem is that most of these verbs can't be classified as either
without significant research, which makes this a rather poor programming
technique. Here they are:
<a href="
http://www.moo.ca/player:read_lines">1</a>
<a href="
http://www.moo.ca/guest:_kick">2</a>
<a href="
http://www.moo.ca/connectable:beep">3</a>
<a href="
http://www.moo.ca/garbage:valid">4</a>
<a href="
http://www.moo.ca/no_one:give_quota">5</a>
<a href="
http://www.moo.ca/lazy_heap_utils:rec_heap_length">6</a>
<a href="
http://www.moo.ca/lazy_heap_utils:rec_tree_length">7</a>
<a href="
http://www.moo.ca/web:parse_message">8</a>
<a href="
http://www.moo.ca/webber:match_object">9</a>
<a href="
http://www.moo.ca/webber:boot_good">10</a>
<a href="
http://www.moo.ca/output_queue:do_null_command">11</a>
<a href="
http://www.moo.ca/encrypt_utils:encode_rail_fence">12</a>
<a href="
http://www.moo.ca/file_warehouse:cleanup">13</a>
<a href="
http://www.moo.ca/128:cat">14</a>
<a href="
http://www.moo.ca/complex_utils:divide">15</a>
<a href="
http://www.moo.ca/cvsfo:import">16</a>
<a href="
http://www.moo.ca/601:_kick">17</a>
<a href="
http://www.moo.ca/601:handle_expose">18</a>
<a href="
http://www.moo.ca/602:glNormal">19</a>
<a href="
http://www.moo.ca/605:handle_expose">20</a>
<a href="
http://www.moo.ca/650:refresh">21</a>
<a href="
http://www.moo.ca/dfa:_initialize">22</a>
<a href="
http://www.moo.ca/7990:reapable">23</a>.
Contrast with Cecil's
<a href="
http://www.moo.ca/const:tell_contents">$const:tell_contents</a>.<P>
<li><a href="
http://www.moo.ca/12%3A%40netforw*ard">$player:@netforward</a>
and <a href="
http://www.moo.ca/bug%3Abug">$bug:bug</a> are +x verbs (for
reasons I can't fathom -- nobody calls them) that depend on "player !=
this" as a security check. Best fix is simply to chmod them -x.<P>
<li>Worse is <a href="
http://www.moo.ca/12%3Anetforward">$player:netforward</a>
which is a tnt verb that also relies on "player != this". Anyone can
netforward other people's mail by trapping their notify verbs. Also,
this verb shouldn't return errors, it should raise them.<P>
<li>A number of objects have "help_msg" files. These should have been
renamed to "msg_help" two years ago when Manta changed the format. The
following objects need to have their help files renamed and chmoded +r:
<a href="
http://www.moo.ca/62%21help_msg">#62</a>
<a href="
http://www.moo.ca/338%21help_msg">#338</a>
<a href="
http://www.moo.ca/1107%21help_msg">#1107</a>
<a href="
http://www.moo.ca/1228%21help_msg">#1228</a>
<a href="
http://www.moo.ca/1341%21help_msg">#1341</a>
<a href="
http://www.moo.ca/1579%21help_msg">#1579</a>
<a href="
http://www.moo.ca/2735%21help_msg">#2735</a>
<a href="
http://www.moo.ca/3100%21help_msg">#3100</a>
<a href="
http://www.moo.ca/5746%21help_msg">#5746</a>
<a href="
http://www.moo.ca/6886%21help_msg">#6886</a>
<a href="
http://www.moo.ca/7351%21help_msg">#7351</a><P>
<li>No security on
<a href="
http://www.moo.ca/334%3Aget_data%20set_data">#334:set_data</a>.
Doesn't affect the Moo, but it does mean anyone can mess up Raptor's
guestbook. Also,
<a href="
http://www.moo.ca/334%3Acheck_login">#334:check_login</a>
has multiple problems (which might explain why nothing calls it?).<P>
<li>Shouldn't Manta's
<a href="
http://www.moo.ca/new_root%3Ann%20name_and_number">#1:nn</a>
be -o? I'd think that it would be a bad thing for people to write nn
verbs that dynamically return results based on the caller stack. And I
can't think of any valid reasons to override this verb.<P>
<li>Calling Manta's
<A HREF="
http://www.moo.ca/850%3Acheck_write_perms">#850:check_write_perms($no_one)</A>
allows anyone to kill the current task. This opens up a number of
well-documented exploits.<P>
<li>There are a number of verbs which use kill_task() in a manner that
is currently safe, but are just asking for trouble next time someone
tweaks the verb without realising what lurks within. For instance
the use of kill_tasks instead of returns in
<A HREF="
http://www.moo.ca/19%3A%40recycle-project*%21">$project:@recycle-project</A>,
<A HREF="
http://www.moo.ca/12%3A%40listen%20%40unlisten">$player:@unlisten</A> and
<A HREF="
http://www.moo.ca/13%3A%40ref*erence">$builder:@ref</A>
These verbs are -x, so they are safe. But there is no need to use
explosives when a fly swatter will do.
Somewiz likes playing with fire in
<A HREF="
http://www.moo.ca/3100%3Amoveto">#3100:moveto</A>;
technically line 4 is safe, but pointless. Odo's
<a href="
http://www.moo.ca/safe%3Aset_opened">$safe:set_opened</a>
may have sufficient security, but a bit more wouldn't hurt.<P>
<li>Anyone can change the aliases on the Generic Nexus Exit or any of
its kids, thanks to zero security on
<a href="
http://www.moo.ca/770%3Aset_aliases%20_set_aliases">#770:set_aliases</a><P>
<li>The security checks on
<a href="
http://www.moo.ca/prog_fo%3Astamp%20rem*ark">$prog_fo:stamp rem*ark</a>
are inadequate. As it stands, if you are in an editor and you use any
feature object, the owner of that feature object can stamp and comment
your work. Or if you are in an editor and you use a feature which
emotes or pages someone, that person can hook their notify to stamp and
comment your work. Or better yet, suspend() any feature task while you
are outside the editor, then resume the task when you start editing
something.<P>
<li>Manta forgot to add any security to
<a href="
http://www.moo.ca/sign%3Aset_description">$sign:set_description</a>.
All your $sign are belong to us...<P>
<li>Manta, no security,
<a href="
http://www.moo.ca/console%3Arecord_connection%20record_disconnection">$console:record_connection record_disconnection</a>.<P>
<li><a href="
http://www.moo.ca/4705:_kick">#4705:_kick</a> is cool, it
allows anyone to recycle some 1400 objects with Lao's perms. Applies to
almost anything with a dest property. That means virtually every exit,
emergency transponder and window (including the generics). Even a
programmer: Snoopy (#7721). I wonder how many people I could convince to
add dest properties to themselves (please, it's the last thing I'll ever
ask you to do)...<P>
<li>This is a problem that seems to be repeated over and over again:
_kick verbs are failing to verify that args[1]:isa(this). These same
verbs are also failing to acknowledge that 'this' is not the object to
be manipulated, args[1] is. There are currently 90 _kick verbs, of which
60 are wizardly, and of which 10 have security problems (like the one
above). In the interests of security and consistency, I propose that
every one of them be prefixed with: <tt>{object} = args;
object:isa(this) || raise(E_INVARG, "Illegal object", object);</tt> Then
#1:kick could be programmed to look for the existence of this totally
consistent check, and refuse to call _kick verbs that don't contain it
(even mailing the owners of non-conformant verbs to explain why it
wasn't called and detailing what they must do to comply).<P>
<li>A hook in your title would allow you to call
<a href="
http://www.moo.ca/5451:heel%20summon%20call">#5451:heel summon call</a>.
As soon as anyone checks @who, any or every object they own could be
moved to their location with Cecil's perms.<P>
<li>Thanks to a lack of security on
<a href="
http://www.moo.ca/5451:cd*">#5451:cd*</a>, anyone can
force_input() to other people's pettable animals, by hooking one of
their tasks (through title or notify). | 0Wn j00r @n|mu1z. Verified
experimentally (sorry Hildegarde). Also, this use of force_input() on
unconnected objects appears to fly in the face of what the help and the
programmer's manual state is possible. If this is an MC server hack,
then it needs to be documented in ?force_input().<P>
<li>Non-wizzen can't use Manta's
<a href="
http://www.moo.ca/101%3Abf_set_connection_option">#101:bf_set_connection_option</a>
because of a programming error on line 5.<P>
<li>It has been Dax's long-standing policy never to touch $project since
I live in terror of being sucked into maintaining that horrible system
with no way out. Little did I realise how accurate this was:
<a href="
http://www.moo.ca/project%3A%40leave%20%40quitte">$project:@leave</a>
commits suicide with traceback rather than letting the victim escape.
Looks like somewiz was thinking about quota contributions while
programming that.<P>
<li>A number of -x verbs return error values (usually E_PERM). This
should not happen as return values are ignored when invoked from the
command line. If there is an error, it must be printed. This isn't a
security issue, just a usability issue. Commands shouldn't do nothing
(whee, an intentional double negative). Here are the wizardly instances:
<a href="
http://www.moo.ca/player%3A@typo%20@suggest*ion%20@idea%20@comment">$player:@typo</a>
<a href="
http://www.moo.ca/player%3A@lastlog">$player:@lastlog</a>
<a href="
http://www.moo.ca/player%3Afinger%20@finger">$player:@finger</a>
<a href="
http://www.moo.ca/player%3A@new-macro%20@macro">$player:@macro</a>
<a href="
http://www.moo.ca/player%3A@set-macro">$player:@set-macro</a>
<a href="
http://www.moo.ca/player%3A@rm-macro%20@remove-macro">$player:@rm-macro</a>
<a href="
http://www.moo.ca/player%3A%21*">$player:!*</a>
<a href="
http://www.moo.ca/teacher%3Afinger%20@finger">$teacher:@finger</a>
<a href="
http://www.moo.ca/wiz%3A@make-player%20@new-player%20@makeplayer%20@newplayer">$wiz:@make-player</a>
<a href="
http://www.moo.ca/guest%3A@give">$guest:@give</a> (with French)
<a href="
http://www.moo.ca/pie%3Asafe%20unsafe">$pie:safe</a>
<a href="
http://www.moo.ca/3135%3A@labeltrash">#3135:@labeltrash</a>
<a href="
http://www.moo.ca/mad%3Acsay%20c%3A%20c%3E%20cspoof">$mad:csay</a><P>
<li>Not only should -x verbs not eat a command without doing anything,
they should also not spit back a traceback. There is no reason for a -x
verb to use raise(). After all, these errors can't be trapped by a verb
higher up the stack, since there is no stack. Using raise() to print a
non-existent stack is silly. The following wizardly verbs should print
messages, then return:
<a href="
http://www.moo.ca/player%3A@iplist%20@uniplist">1</a>
<a href="
http://www.moo.ca/player%3Aduzzendonuthin">2</a> <s>
3 4 5 </s>
<a href="
http://www.moo.ca/guardian%3A@toast*%21">6</a>
<a href="
http://www.moo.ca/guardian%3A@check-site">7</a>
