Analysis of the bug
===================

The `do_userdata()` function doesn't check the provided file name in any way.
Therefore, an attacker can create files in any directory where the remote
server has write access.

Attack plan
===========

The idea is to exploit the bug to create a keyword file that, when expanded in
the command passed to `system()` in `do_grep()`, will terminate the `grep`
command and then start a shell.
This is possibile since we can create a userdata file in the `../keywords`
directory and `do_userdata()` will let us write arbitrary characters in it.

Attack implementation
=====================

We connect a first time and create the fake keyword file:
```
nc $HOST $PORT
u../keywords/1
' x;sh;
^C
```
Note that the resulting command will be `/usr/bin/grep 'INPUT' userdata/*`,
where INPUT is the contents of our userdata file (the second third line above). We need
to terminate the single quote, otherwise the shell called by `system()` will error-out
before giving us an interactive shell. With the above INPUT, the command will become
```
/usr/bin/grep '' x;sh;' userdata/*
```
which is syntactically correct up to the invocation of `sh`. We don't care about the
rest.

Note also that we have to close the connection, since `do_userdata()` reads up to the EOF.

Now we connect a second time:
```
nc $HOST $PORT
g1
```
We will see `grep` complaining about the non existing `x`, and then we will be able to interact
wit the remote shell. The flag is in the `secret` file.

Suggested fix
=============

The `do_userdata()` function should carefully check the name of the file it is creating.
Probably the safest thing to do is to only accept alphanumeric characters.