Over two years have passed since I’ve done any significant development on my encrypted chat program, Cryptully. In that time, a few issues with it have arisen and some issues were left outstanding from when development ramped down. Some of the larger items that needed to be addressed were:
Most severe: The SMP MITM attack detection implementation was ironically vulnerable to MITM attacks.
The hard coded DH prime was not uniquely generated.
The tests have been failing for over two years.
There was no way to for the server to determine what version of the program a client was running.
The documentation for running and building the program had become out of date.
I have never gone back to a project after such a long period of time to fix bugs and add new features. Overall, I was pleasantly surprised at how well the code had aged after being neglected for two years. That is, everything still worked with the most recent versions of the libraries and frameworks I used and there were only a few spots where I wondered what the hell I was thinking when I wrote that code. However, there were a few challenges in fixing some of the long standing issues outlined above.
As I was working my way through the chapter on memory management in Understanding the Linux Kernel I thought it would be fun to try to write a program that translates a virtual memory address to a physical address. Moreover, I wanted to do it user space. And to go one step further, why not try to get the physical address of a buffer, go to that location in memory, modify it, and then see the changes by using the virtual address.
WARNING: I am far from a kernel expert. Everything here is me just documenting my experimentation with the kernel. It is very likely that mistakes and incorrect information are present. Please email me with any corrections.
There are a few problems with trying to accomplish this task in user space:
The idea behind virtual memory is to provide an address space of contiguous memory. The memory for a process is most likely stored in non-contiguous blocks.
There’s no guarentee that a page is even in the physical memory of the system. It could be in the swap or in a cache somewhere. There could be no physical address to get!
For obvious security reasons, a process does not have access to the raw memory of the system, even if the process’s UID is 0.
There’s two approaches we can take to get the physical address:
Add a syscall to the kernel that, given a virtual address, will return the physical address. However, modifying the kernel breaks the rule of doing everything from user space so we have to rule this out.
Use the pagemap file for a process (added in kernel 2.6.25) to get the frame a page is mapped to and then use that to seek into /dev/mem and modify the buffer there.
Using this approach, it’s entirely possible to translate a virtual address to a physical address in user space. However, verfying our translation is correct requires reading /dev/mem. This does require one small modifcation to the kernel (changing a config option), but more on that later.
As of August 2014, WebRTC is still a new and untamed beast. As such, I found that there is a lack of simple and easy to understand examples for someone getting started with WebRTC. My goal was to create my own, as simple as possible, proof of concept WebRTC video conference page that achieved the following goals:
1-to-1 video chat
Pure WebRTC; no external libraries
Works in current versions of Firefox and Chrome
Before getting into the actual WebRTC APIs, it’s best to understand a simple signaling server. For those unaware, WebRTC requires that peers exchange information on how to connect to one another before the actual connection can be begin. However, this exact method is left up to the developer. It could be anything from a very complicated server to peers emailing one another. For my purpose, I chose to write a short and sweet Node.js server that communicates with clients via websockets.
Note: The full example is available on GitHub. As WebRTC evolves the content on this page may become out of date. See the GitHub repo for the most up to date example.
I’ve long had an interest in Linux, and by Linux I mean the actual Linux project, ie. the kernel, not GNU/Linux, but getting into kernel development is an incredibly difficult task to accomplish. Linux has millions of lines and is one of the largest software projects in the world. Not to mention that the Linux kernel mailing list can be an intimating place. In all, it’s not something that you just jump into on a whim.
I’ve been using GNU/Linux for over six years now. I’ve become very comfortable with it and C. I’ve read kernel code in the past, but never written any. My goal was to dip my toe in and test the waters of writing some kernel code. I figured that a good way to do this was to try to add my own custom syscall to Linux. And to have some fun with it, I decided that this syscall would work like the setuid syscall except that it would change the uid of the calling process to 0 without any authentication checks. That’s right, this sucker is completely subverts all security in the kernel and is essentially a rootkit. As usual, my goal here is purely academic, not malicious. Considering employing this would mean completely changing the kernel of a system, I’d hardly consider it a vulnerability. If you’re able to change the kernel of a system, all security has already gone out the window.
Note that at the end of this process, if you want to try it out, you’ll need to compile your own kernel. This isn’t a guide on how to compile the kernel so you’ll need to look up that process for yourself. However, if you’re on Ubuntu, the Ubuntu wiki has a pretty good guide.
That said, let’s dive in and see what files need modified. If you haven’t already, you’ll want to get a copy of the source with:
Linux is massive and I’m no magician so I needed a little help on where to start looking. A quick search revealed this guide: http://www.tldp.org/HOWTO/html_single/Implement-Sys-Call-Linux-2.6-i386/ which turned out to be a very good resource. The only problem is that is slightly out of date being written for Linux 2.6 and for x86 architecture. Let’s see if we if make this work on the current version of Linux 3.14 (at the time of this writing) and for x86_64.
I’ve recently given myself the task of creating a mature workflow for a Drupal website. For the past few months, I have been working with a startup and creating their website from the ground up. We are using a traditional LAMP stack with Drupal running on top. Sure, the LAMP stack isn’t the “in thing” anymore, but it’s working very well for our purpose right now. That is, get up and running quickly and focus on developing the product.
At first, development was easy. Throw Drupal on an EC2 instance and jump in to writing code. But, of course, sooner than later real data starts being entered into the database. The website starts being used for demo purposes and, well, if a poorly written function blows away a database table, that’s a serious problem. So, we need a more mature workflow. Something that will allow for those poorly written functions to light the whole database on fire and not have it matter because it’s just a copy of the real database or if the unthinkable does happen, it’s easily recoverable. Unfortunately, the nature of Drupal doesn’t make this as easy as it should be.