Up to Main Index                          Up to Journal for February, 2019

                   JOURNAL FOR THURSDAY 14TH FEBRUARY, 2019
______________________________________________________________________________

SUBJECT: Details on security issue, fixed in WolfMUD v0.0.13
   DATE: Thu 14 Feb 19:22:07 GMT 2019

By now I hope you have seen that WolfMUD v0.0.13 has been released[1][2] and
that it contains a fix for a security issue. I wasn’t planning on a release
just yet, so things were a little rushed. As a result there are some things
included which are not as polished as I would have liked — noted in the known
bugs section of the release notes:


  Known Bugs

  - New search and matching item limits and item instances undocumented.
  - Alias qualifiers, aliases with a leading '+' character, have not been
    documented yet.
  - Commands will recognise a qualifier as a valid alias. For example with
    aliases '+GREEN' and 'BALL' commands will see the qualifier '+GREEN' as
    a valid alias. So 'GET +GREEN' would work for the item when it shouldn't.


The inclusion of these changes was mainly due to the fact I had already pushed
changes to the public dev branch and didn’t have a workflow in place for
releasing v0.0.12 plus just the security fix. I could have created a git
branch for the fix off of v0.0.12 and then folded the fix into the dev branch.
I didn’t. As a result the new search and match code is out with the new WHICH
command for testing it, which is not all bad.

So what happened?

I started off the month by quietly working away on WolfMUD and sorting out
automating the testing of player commands. One particular issue I was tussling
with was whether or not to validate command output with or without colours. I
had already written some code to strip the ANSI control sequences from
messages and it made the testing a lot easier. However it also made the tests
very artificial. So I switched back to testing with the ANSI control sequences
in the messages. In the end I managed to simplify things a lot and it wasn’t
such a big deal.

Then I spotted the issue…

It started innocently enough, a quick test on the command line:


  echo -e 'user\npassword\n1\nsay test\nquit\n0\n' \
  | netcat 127.0.0.1 4001


Then I tried injecting some colour:


  echo -e 'user\npassword\n1\nsay \x1b[32mtest\nquit\n0\n' \
  | netcat 127.0.0.1 4001


I then tried other ANSI escape sequences like BEL (bell, ASCII 0x07, ^G). That
worked as well, which wasn’t good. I then played with sequences for moving the
cursor on the screen and setting the terminal title. This met with some
success and a few failures. If there was another player at the location where
I used SAY command the data would be sent to them and affect their client
and/or terminal. You could ring their bell, set the terminal title and
everything else. It turns out I could in fact send nearly any data via the say
command. Oh, crap! or words to that effect :(

For an idea of how serious rouge escape sequences can be, depending on the
Telnet client and terminal emulator being used, I highly recommend reading the
paper ‘Terminal emulator security issues’ by H. D. Moore:

  https://marc.info/?l=bugtraq&m=104612710031920&q=p3

Makes for some very grim reading…

I pushed everything I was working on to one side and proceeded to start
working on a fix. In fact I came up with four or five fixes. In each case
performance became an issue — due to the fact that all user input was going to
have to be validated. It took me a week to come up with a solution I was happy
with. The old version of the code had a comms.fixDEL function that performed
character deletion when raw BS (backspace) and DEL (delete) codes were sent by
the client. The fixDEL function was already scanning all incoming data and
seemed a natural place to fix all data and not just deletions. Eventually I
dropped comms.fixDEL and replaced it with comms.clean instead. This new
function drops C0 and C1 control codes, except for BS and DEL, validates the
UTF-8 encoding, handles raw BS and DEL sent by clients[3] — and deletion still
works with combining code points. To top it all off it is more performant than
the original comms.fixDEL for all common cases of data and only slows down a
little when handling the deletion of Unicode in the data stream. Most clients
are sending ASCII and have line editing capabilities.

If anyone has any issues with the release, the new code, performance, specific
clients or anything else then please don’t be shy, let me know. I can’t fix
things I don’t know about. Just a simple email to diddymus@wolfmud.org is all
it takes.

--
Diddymus

  [1] Download area: 10.html

  [2] Download area: ../../../downloads/

  [3] This can happen when the client does not support line editing or is not
      in line-at-a-time mode.


  Up to Main Index                          Up to Journal for February, 2019