Up to Main Index Up to Journal for May, 2017
JOURNAL FOR TUESDAY 2ND MAY, 2017
______________________________________________________________________________
SUBJECT: More on the security update
DATE: Tue 2 May 23:31:22 BST 2017
After yesterday’s security update[1] I’ve been asked quite a few questions
which I will try to answer here, with as much information as I can, so as many
people see it as possible.
The security issue was a local information disclosure vulnerability. For the
vulnerability to be exploitable a user must gain local access to the machine
the WolfMUD server is running on. The user must then have access to either a
heapdump file or the WolfMUD server’s memory. The heapdump file or memory may
contain user passwords in plain text that linger in memory after use.
The heapdump file is produced via ‘#DEBUG heapdump’ when logged into WolfMUD.
The #DEBUG command was only available on the public dev git branch — not in a
publicly released version. The #DEBUG command also has to be enabled by
setting Debug.AllowDebug to true in the data/config.wrj configuration file.
The worst error made here was that the heapdump file was world readable — this
has been corrected in the security update.
For any version of WolfMUD it is possible that clear text passwords lingering
in memory could have been discovered — the risk is deemed minimal due to local
access being required with elevated permissions and tooling available. Access
to the server’s memory is usually accomplished using debugging tools, for
example gdb and gcore. However a local user must first gain permissions to the
process in order for the tools to work. Any user who can accomplish this is
already a potential threat to the whole machine and not just to the WolfMUD
server!
On Linux and Unix like systems a very simple and secure environment[2][3] to
restrict access to the WolfMUD server, its files and memory can be setup by
creating a separate user and group under which the server runs. WolfMUD can
then be installed in the separate user’s home directory and all files can be
owned by that user. Access will then only be via the separate user/group or
privileged users such as root.
Not having used Windows for a great many years[4], I don’t have anything to
say about WolfMUD on Windows. I’d rather plead my ignorance than hit Wikipedia
for 5 minutes, then spout some nonsense that puts users at risk.
The actual information disclosure is due to the fact WolfMUD reads input from
the player and stores it in a variable. That variable is in memory. Memory can
be dumped to a file or inspected directly — gaining access to the data stored
in the variable. This is not a problem unique to WolfMUD or Go — any program
written in any language will store data in variables in memory.
To mitigate the problem WolfMUD now retains input for as short a time as
possible and does not depend on garbage collection to dispose of data after
use. Care is taken to not create additional copies of input via appending to
slices — in which case the copy would linger until garbage collected. Care is
also take to write zero bytes into slices before releasing them for garbage
collection. Any files created by WolfMUD — blockprof, cpuprof, heapdump,
memprof and player account files — are only readable and writeable by the user
and group the WolfMUD server is running as.
With these precautions there remains a brief window of opportunity — between
WolfMUD reading input and processing it — where plain text passwords will be
held in memory. Running WolfMUD in a secure environment with restricted access
will prevent the memory from being snooped on as much as possible.
To put things into perspective, all of this pales in comparison to the fact
that WolfMUD uses Telnet where there is the issue of plain text passwords
being sent across an untrusted network — the internet.
If anyone still has questions: diddymus@wolfmud.org
--
Diddymus
[1] Journal entry for 1st May, 2017: 1.html
[2] Some people asked about running WolfMUD in a chroot. Chroot is designed
to stop users and processes “getting out” not users “getting in”. But,
the WolfMUD server can be run in a very minimal chroot with only the
following system files available:
/lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libpthread.so.0
/lib64/ld-linux-x86-64.so.2
This is on a 64-bit x86 Debian system. The command ‘ldd server’ will
show you what files are needed, but you can omit linux-vdso.so.1.
[3] If there is available hardware, for example a Raspberry PI, that can be
dedicated to running WolfMUD then a small script that starts networking
and then calls the server executable can be specified for the init
kernel boot parameter. See also: ../../2012/12/20.html
[4] I have a copy of Windows 10 Pro running in a VM for Work to test
websites in Internet Explorer. I also sneak in some WolfMUD testing.
That’s all I use Windows for, nothing else, not even games.
Up to Main Index Up to Journal for May, 2017