Back to the Floor

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.

I have been a wizard on Moo Canada 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.


The log:

  1. Manta's hack to $room:announce*_all_but 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".

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

  3. $builder:@grep needs the following at the top (not a security hole, though):
    if (player != this)
      return $msg:mtell("huh");
    endif

  4. The same needs to be added to $guardian:@necronomicon (the current check issues a message, but forgets the return).

  5. Line 31 on $exit:move blows up before printing Manta's error message. The same error appears in $vexit::move which is a copy of $exit:move.

  6. Lines 59, 78 and 98 in $builder:@grep! blow up for non-wizzen. s /0, caller_perms()//1-$

  7. There are some fishy properties and files on $no_one. 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.

  8. $builder:@dump 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 $builder:@rawdump (line 102) and to $dump:do_www_dump (line 118) due to verb copying.

  9. Guardians can see failed web passwords by sniffing argstr or dobjstr in the cracker messages from $webber:Authorization:. 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.

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

  11. 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: 1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23. Contrast with Cecil's $const:tell_contents.

  12. $player:@netforward and $bug:bug 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.

  13. Worse is $player:netforward 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.

  14. 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: #62   #338   #1107   #1228   #1341   #1579   #2735   #3100   #5746   #6886   #7351

  15. No security on #334:set_data. Doesn't affect the Moo, but it does mean anyone can mess up Raptor's guestbook. Also, #334:check_login has multiple problems (which might explain why nothing calls it?).

  16. Shouldn't Manta's #1:nn 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.

  17. Calling Manta's #850:check_write_perms($no_one) allows anyone to kill the current task. This opens up a number of well-documented exploits.

  18. 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 $project:@recycle-project, $player:@unlisten and $builder:@ref 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 #3100:moveto; technically line 4 is safe, but pointless. Odo's $safe:set_opened may have sufficient security, but a bit more wouldn't hurt.

  19. Anyone can change the aliases on the Generic Nexus Exit or any of its kids, thanks to zero security on #770:set_aliases

  20. The security checks on $prog_fo:stamp rem*ark 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.

  21. Manta forgot to add any security to $sign:set_description. All your $sign are belong to us...

  22. Manta, no security, $console:record_connection record_disconnection.

  23. #4705:_kick 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)...

  24. 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: {object} = args; object:isa(this) || raise(E_INVARG, "Illegal object", object); 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).

  25. A hook in your title would allow you to call #5451:heel summon call. As soon as anyone checks @who, any or every object they own could be moved to their location with Cecil's perms.

  26. Thanks to a lack of security on #5451:cd*, 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().

  27. Non-wizzen can't use Manta's #101:bf_set_connection_option because of a programming error on line 5.

  28. 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: $project:@leave commits suicide with traceback rather than letting the victim escape. Looks like somewiz was thinking about quota contributions while programming that.

  29. 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: $player:@typo   $player:@lastlog   $player:@finger   $player:@macro   $player:@set-macro   $player:@rm-macro   $player:!*   $teacher:@finger   $wiz:@make-player   $guest:@give (with French)   $pie:safe   #3135:@labeltrash   $mad:csay

  30. 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: 1   2   3   4   5   6   7