# [SECURITY] Re: force_input() and $do_command()

Gustavo Glusman (bmgustav@bioinformatics.weizmann.ac.il)
Sun, 7 Jul 1996 00:54:14 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    >>At 12:06 PM 7/4/96 PDT, Jefferson Dubrule wrote:
    >Also, this verb needs to be added:
    >....
    >Please let me know if this opens up horrible security holes or something.

    OK, here we go -

    >@verb $wiz:"@animate" any none none

    While this verb is !x, and therefore you might think it needn't check
    permissions, notice that its arguments (any none none) allow for abuse from
    any user. Example:
    A guest connects, and types: @animate #2
    The verb gets matched on the dobj, and activated.

    >@program $wiz:@animate
    >if (valid(puppet = $string_utils:match_player(dobjstr)))

    This line assigns #2 to 'puppet', after matching successfully the string "#2".

    >  $network:animate(puppet);

    This second line calls $network:animate on #2 (the puppet), *with the
    original permissions*. Let me guess this was actually wizperms?
    Then, we have:

    >@verb $network:animate tnt
    >@program $network:animate
    >":animate(player)";
    >"Open a dummy network connection that simulates the connection of a player.
    >The object
    >specified must be a player (though it need not be a $player).";
    >if (typeof(args[1]) != OBJ || !valid(args[1]) || !is_player(args[1]))
    >  return E_INVARG;

    All these checks are okay, we proceed -

    >elseif (!$perm_utils:controls(caller_perms(), args[1]))
    >  return E_PERM;

    As we're with wizperms, we proceed -

    >elseif (typeof(connection = open_network_connection("127.0.0.1", this.port))
    >== ERR)
    >  return connection;
    >else
    >  this.animations = {@this.animations, {connection, args[1]}};
    >  return connection;
    >endif
    >.

    So the guest managed to open the network connection, and assign puppet #2
    to it.
    We go back to the @animate verb:

    >  player:tell($string_utils:nn(puppet), " animated.");

    'player' is still the guest, so it gets notified of success. #2, who might
    be connected, has no clue of what is going on. If the line read
    "this:tell(etc)", things might be somewhat different.

    >else
    >  return player:tell("Invalid player, \"", dobjstr, "\".");
    >endif
    >.

    Now, we have:

    >@verb $wiz:">*" any any any
    >@program $wiz:>
    >if (verb[1..2] == ">>")
    >  puppet = $string_utils:match_player(verb[3..$]);
    >  if (!valid(puppet))
    >    return player:tell("Invalid player name, \"", verb[3..$], "\".");
    >  endif
    >  player.puppet = puppet;
    >else
    >  puppet = player.puppet;
    >  (length(verb) > 1) && (args = {verb[2..$], @args});
    >endif
    >force_input(puppet, $string_utils:from_list(args, " "));
    >.

    Again, both 'any' for dobj and iobj enable the abuser to sneak #2 (or some
    other perms), even though nominally s/he doesn't have access to this verb.
    As a .puppet property is required here, a guest will have a harder time,
    but a programmer can do it.
    If a wizard is online, a suitable > command can be concocted to force_input
    some nasty command in. As many core commands keep talking to player, a
    programmer could be evalling with wizperms, and the wizard might fail to
    notice.

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