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