The idea of a secure virtual environment for running contracts is good. Moxie is simple virtual machine with 14 general-purpose registers, a stack pointer and a program counter.
Jeff Garzik has proof-of-concept moxie sandbox called moxiebox. You give it a compiled moxie ELF binary, and a file of input data. You optionally request where to receive a file of output data. The sandbox will will return with an exit code 0 on success and nonzero if there's an error.
The setup is so simple, that I think it easy to reason there are few places there can be security flaws.
Moxiebox runs just one program, the contract. To run code, you use a GCC or clang a cross compiler to output the moxie elf binary
There isn't adequate documentation for how to set up moxiebox from source. What I did was take the Travis continuous integration instructions (in travis.yml) and replicated this in a vagrant virtual machine. This VM is Ubuntu 12.04.5 "precise". From these you can get the GCC toolchain binaries (gcc, gas, ld, ranlib, nm). I tried other sources from Moxie such as Fedora core and RedHat/Centos rpms and these didn't work on Moxiebox.
The Ubuntu code didn't include gdb, andn gdb is the only suggested way to debug programs. So used the instructions in moxie-cores to try to build gdb and have a source-code base to work in.
I was not able to correctly build gcc as it requres a special loading:
$ /home/vagrant/moxiebox/local/root/usr/bin/moxiebox-gcc -dumpspecs
*asm:
-EL
...
*lib:
%{!T*:-Tmoxiebox.ld} %{!nostdlib: --start-group -lsandboxrt -lc -lgcc --end-group }
Note in the above there are no shared libraries and it uses nostdlib and includes sandboxrt. I am not aware that these specific features are not mentioned explicitly.
The code is very sensitive. To run the gcc tests, you need have at least -O1 optimization. If there is an error in the code I don't believe you can get a traceback.
If there is output and the sandbox invocation didn't give a place for output, that is an error. Or vice versa. Same thing for input.
The other bad news is that dynamic memory allocation is not fully implemented. There is a run-time _mmap_which will allocate memory pages dynamically but no sbrk which is typically what malloc uses to grow memory allocation. Since I couldn't build gcc and the libraries clean enough, what I resorted to doing was removing mallocr.o from libc and recompiled that making changes the code to avoid using sbrk. When I build programs I include that code in. Better would be add this back to the libc archive.
Even better would be to implement some sort of sbrk.
I have a vagrant virtual machine called moxiebox-ubuntu12. The account there is "vagrant" and you can "vagrant ssh" to that whien it is up.
Inside that is a "moxiebox" directory which has the github code and additions I've modified. My code is in a "rocky-hacks" branch.
Little example code I have is in the examples directory. Basically I just tested hashing and wrote a couple of hello world programs.
In examples/common.h I have boilerplate setup and teardown code to give the appearance that you can issue print statements. Did I mention that "printf" and "fprintf" functions don't work?
That virtual machine mounts source from my thinkpad laptop in /src/moxie-cores. This is from Anthony Green's github repository with some changes and code has been built inside that.
I'm not sure folks would want to write contracts in C or C++. Lua is a possibility though and there is however a Lua to C translator
If there are questions about any of this code please feel free to contact me.