writing safe code

What with the all the hoopla these days about the Internet of Things and the simply horrible (horrible, I tell you!) lack of security in many of these devices, I thought I’d throw my two cents into the discussion about simple but effective things you can do to help make such devices more secure. No, really. I’ll start my pontificating off by doing what I do best, writing a small, sloppy C++ program to illustrate a point.

#include <cstring>#include <iostream>int main() {char *inputBuffer = new char[10];char *inputBuffer2 = new char[10];std::cout << "Type something: ";gets(inputBuffer2);std::cout << "You typed 1st: " << inputBuffer2 << " : " << std::strlen(inputBuffer2) << std::endl;std::cout << "Type something: ";gets(inputBuffer);std::cout << "You typed 2nd: " << inputBuffer << " : " << std::strlen(inputBuffer) << std::endl;std::cout << "You typed 1st: " << inputBuffer2 << " : " << std::strlen(inputBuffer2) << std::endl;return 0;}

The program throws out prompts asking you to enter strings of text. It places the string input into two character arrays, inputBuffer and inputBuffer2, using standard C’s gets(), one of the most unsafe ways to do this. As a consequence this program is Unsafe; if compiled with gcc/g++, the resultant compiled application will actually issue a “warning: this program uses gets(), which is unsafe.” warning when executed. Programmers who use standard C’s gets() are just begging to get mugged on dark streets in the big city.

The single biggest problem with this program is it’s using standard C’s gets() to read data and to place it into the two arrays. Why is that a problem you innocently ask? Both arrays are limited to 10 characters each. Standard C’s gets() doesn’t care one wit how many you enter. You can blow right past that limit by typing any string greater than 10 characters and gets() will happily put all that input into memory, starting with the zeroeth character location of both arrays. Absolutely no attempt is made to limit input. Now watch what happens when my small sloppy example’s run.

Type something: first input stringYou typed 1st: first input string : 18Type something: SECOND INPUT STRINGYou typed 2nd: SECOND INPUT STRING : 19You typed 1st: ING : 3

Oh my goodness, what happened? Because of the way I allocated those character buffers, and then the way I used them, my second input string overwrote my first. In other words my second input string data corrupted my first input string. Thus printing my first input string actually printed the last three characters of the second inputed string. And that’s because both character arrays were allocated with only ten characters each. How should it look if it were safe? Let’s look at the same code, but written not nearly as sloppily. I’ll replace the bare allocated character arrays with instances of C++’s std::string and use C++’s getline() standard library call.

#include <iostream>int main() {std::string inputBuffer;std::string inputBuffer2;std::cout << "Type something: ";getline(std::cin, inputBuffer2);std::cout << "You typed 1st: " << inputBuffer2 << " : " << inputBuffer2.length() << std::endl;std::cout << "Type something: ";getline(std::cin, inputBuffer);std::cout << "You typed 2nd: " << inputBuffer << " : " << inputBuffer.length() << std::endl;std::cout << "You typed 1st: " << inputBuffer2 << " : " << inputBuffer2.length() << std::endl;return 0;}

Now let’s run that code and see what happens:

Type something: first input stringYou typed 1st: first input string : 18Type something: SECOND INPUT STRINGYou typed 2nd: SECOND INPUT STRING : 19You typed 1st: first input string : 18

Now the strings are behaving the way you’d expect them to. Both are read in and neither one overwrites the other. The key to this is reasonable resource management. I used the C++ string class to provide simple but effective character resource management. No matter how many characters I typed in at the prompts, both string instances would have provided the necessary space internal to each instance to hold those characters, without having to worry that one would corrupt the other. So remember folks, in spite of what Linus says about C++, it’s actually better to use C++ than bare-bones C, even if fgets() is better than gets() in standard C.

I’m writing about this specific kind of programming because a lot of security exploits occur when resources aren’t properly managed and buffer overflows occur. Buffer overflows can result in everything from data corruption to the execution of arbitrary code, leading to permission escalation and all sorts of mean nasty things.

Good resource management can take you a long way in programming. Now if you can just remember not to hard code back doors into the code…

haiku

Haiku running in VMware Player on Windows 8.1 host

So I’m sitting in my hotel room late one evening here in Tokyo, and for whatever reason I got a wild hair to try out Haiku in VMware Player (version 6.0.5 build-2443746, the latest). Maybe it was this recent article about it on OSNews that got me curious. Installation is certainly simple enough. And once installed it came up and allowed me to play with it a bit. It’s the first time in years I’ve tried Haiku, and from my experience with BeOS, it’s as close as I remember BeOS 4 and BeOS 5 running on one of my very ancient boxes around early 2000 (oh my, fifteen years ago…).

In this case I fired up the old GL Teapot demo and then brought up Windows 8.1’s resource monitor. 360 frames/second isn’t too shabby, especially for a VM. If I did decide to contribute or otherwise fool around with this OS, running it on the VM would certainly be quite doable. The only problem (so far) is moving files back and forth between the VM and the local host. I can’t install the VMware Tools on this VM.

Considering just how light-weight (i.e. resource usage wise) that Haiku is, it makes me wonder how hard it would be to port this to ARM and something like the Raspberry Pi 2 with its quad-core ARM v7 chip. There seems to have been some interest in cross-compiling to the earlier RPi back around 2012, and there’s a page on the Haiku wiki about compiling Haiku for ARM. Not that I have a lot of cycles these days. I guess we’ll just have to wait and see. I would certainly use it as an alternative to Linux on those boards.

Certainly something to think about.