Archives For January 2016

iron tulips

I have been using my first Olympus E-M5 again, the one I purchased January 2013. I bought it back when Lucy was still alive. I have the session of her checking it out when I first pulled it out of the shipping box from Amazon. It had developed a crack on the bottom edge of the pull-up LCD, and so I put it in a drawer thinking I’d get it fixed by Olympus, when I could get around to it. It sat in that drawer for a year until I couldn’t stand it anymore, so I pulled it out, put some super glue on the crack, and continued to use it. While the world goes ga-ga over the latest Olympus camera releases, I continue on with the original body that started the current revolution. I still find it’s as good as the day I purchased it.

I’ve taken everything off the body and put on the newest 14-42mm kit zoom, the EZ pancake. With that combination and a spare battery I’ve been going around as light as possible just so I can have something with me a bit more sophistication than the iPhone. No, I’m not backsliding on the iPhone. The built-in camera is still excellent. But I like to have my options open. That’s why I keep turning back to my Olympus cameras.

Today my wife and I went out for Sunday lunch at Chuy’s on I-Drive. I love the place for its food as well as the wild color scheme around the restaurant. I came back home and worked a bit with the raw files using Lightroom 6.4. More to come…

sectionsliving greens

Here’s Lucy checking things out. The other two cats, Lulu and Ellipse, don’t care. The Gingersnaps, now that’s another story. They seem quite curious about my camera gear.

Lucy Checks Out Her New Olympus OM-D

the critters

January 31, 2016

hey!

Here, in no particular order, are some interesting photos of some of the critters that live with me and my wife. They fill our lives with joy and keep us entertained and on our toes (if not standing on our toes). They are, from top to bottom, Annie, Ponder, Ruby, and Annie again. I try as best I can to capture little moments from their lives. I have no favorites, I love them all. However, I have to admit that as Annie gets older she’s looking more and more like a living Muppet. She reminds me of Animal.

look into my eyes...

my pink gorilla

my pink gorilla

the fallacy of safe code

January 31, 2016
Ken Thompson

Ken Thompson

In the last post I wrote about a simple way to help create so-called safe code, or code that executes correctly. I wrote that code in C++ using gcc/g++ (the GNU Compiler Collection). What was implied, but never explicitly addressed, was my use of the gcc standard libraries along with the compiler, and the implicit trust I put into both not to do evil with my small application. It’s that trust I want to address in this post. I’ll start that discussion by quoting from Ken Thompson (co-creator of Unix and the C language) and his 1984 ACM Award lecture, “Reflections on Trusting Trust“:

You can’t trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. (emphasis mine)

The entire paper is devoted to the Thompson Hack, a method he came up with for creating what he (and later, many others) thought at the time was an undetectable way to create malicious versions of critical applications by compromising the C compiler itself in an undetectable manner. For an example he spoke of adding a backdoor to login if the compiler detected it was compiling login. Although given in 1984, it was actually describing what had been discovered a full decade earlier in 1974. This was pretty interesting and prescient, given today’s revelations. But lest you think that it couldn’t get worse, it actually could. As Ken Thompson continues on in the same paragraph:

In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect.

The comment about microcode is telling; it strikes at the heart of computing, the computer hardware itself. In 2008 the IEEE published “The Hunt for the Kill Switch,” where the authors detailed some of the ways they thought our adversaries could cripple our defense systems (if they hadn’t already) because of hardware kill switches or back doors built into the chips the DoD was buying (they brought up the constantly troubled F-35 as a prime example). Who would put such things into chips? The very people we’ve off-shored chip manufacturing to, primarily the Chinese. Since the 1980s the commercial US chip makers have been pushing chip fabrication and packaging off shore to save money. And the south Asian countries, primarily the Chinese, have been falling all over themselves to oblige. The response at the time was Darpa’s Trusted Integrated Circuits (TRUST). Whether that has had any positive effects has yet to be seen. I personally have my doubts…

Are you sufficiently paranoid yet? Let’s dial that paranoia back a bit. Let’s come back up the rabbit hole a bit into the realm of mere software. Referring back to the Thompson Hack, David A. Wheeler countered with a solution to the Hack titled “Countering Trusting Trust through Diverse Double-Compiling,” in which, you guessed it, Wheeler provides a way to protect yourself from the Hack. The key to Wheeler’s solution is to use a second, trusted, compiler. While the paper is great about the technique, the question about where to get the second trusted compiler is never satisfactorily answered.

But running untrusted code doesn’t have to get this convoluted. You can just pick a commonly used library or tool to use with your system. Consider two of the more egregious errors that led to security lapses: Shellshock and Heartbleed, both disclosed in 2014. Shellshock came about because of buggy code checked into the bash shell sources back in 1992, during a much more innocent period. The web came along and many developers made the decision to use Bash as part of a web server’s execution backend, opening up the Bash remote execution hole. Heartbleed, based on a bug introduced into OpenSSL sometime in 2012, was so devastating because it allowed a MITM attack to grab the encrypted key of digital certificates used to authenticate servers and encrypt traffic between said servers and users. It meant that web servers needed not only to patch their systems, but probably re-apply for all new certificates. Just in case. What led to this was too much code written over too long a period of time and maintained by too few developers paid too little. The folks who wanted something for nothing didn’t bother to look at the open source, thinking someone else had already done the critical vetting. Which just goes to prove the fallacy of Linus’ Law.

I’ve made myself so depressed over reading these types of reports over the last ten to fifteen years that I’ve seriously considered just selling all my computers and such and going to live off the grid. But I’m way too old for that now. Running from the problems means the bad people exploiting all of this win. I hate when that happens. I may not be able to stop them, but I can certainly do my part to slow them down as much as possible; keep my mouth shut while paying attention to what gets published around me in these areas. And keep on, keeping on.

writing safe code

January 27, 2016

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 string
You typed 1st: first input string : 18
Type something: SECOND INPUT STRING
You typed 2nd: SECOND INPUT STRING : 19
You 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 string
You typed 1st: first input string : 18
Type something: SECOND INPUT STRING
You typed 2nd: SECOND INPUT STRING : 19
You 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…

img_0418
Today during lunch I stopped by a big-box store and picked up the Microsoft Universal Foldable Keyboard for $99. I wrote a few posts back about wanting to find a portable Bluetooth keyboard that would work flawlessly with my iPhone and allow me to shift my creative writing urges as much as possible to my iPhone, especially while on the go. A highly portable keyboard such as Microsoft’s is key to this, as trying to type complex post entries quickly and efficiently using the on-screen keyboard is an exercise in sadistic futility.

Having had the keyboard for several hours, this is certainly no in-depth review. But based on what little experience I’ve had so far (writing this entry), it looks to be a solid keeper. It took less than 30 seconds to pair the keyboard with the phone. I like the fact that the keyboard folds up in the middle as you can see by the vertical indentation on the keyboard as well as the illustration on the box. Once folded it slips into my jean’s front pocket along with my iPhone.

Using the keyboard motivates me to stick to using the phone’s camera as much as possible. I took the photo of the keyboard, post-processed it with Snapseed on the phone, then used the WordPress app to upload the final image from my camera roll into the post. The keyboard allows me to quickly write out the post within the app. It takes more time to try and explain the actions than it does to actually perform them.

The only other item I really need to carry with the phone and keyboard are chargers for the phone and keyboard. The con about the keyboard is it requires a micro USB connector to charge. The mitigating pro is that it lasts for three months between charges. Still it would be nice if the power connector matched the iPhone’s lightening connector. As it is I’ll carry the Apple wall-wart and two cables to plug into it, one for the iPhone and the other for the keyboard.

I’ve more experimenting to do with this combination, such as building a post with photos interspersed with text. So far, with this style of WordPress post layout, the universal foldable keyboard is the bee’s knees.

Update Today

I’m not quite so enamored with the WordPress app. Several problems have reared their ugly little heads:

  1. I couldn’t push out a link to this post on either Google+ or Twitter. The controls on the app are there to do this, but when I tried to send out the link I was presented with a login screen for both that wouldn’t allow me to log in. I find this annoying as I’m already logged into both services through their respective apps, as well as being logged into WordPress via the WordPress app.
  2. When it uploaded the lead photo of the keyboard it left it in an odd state. Normally I keep everything at a 500 px width and center aligned, going back in with the web browser editor to adjust both later as needed. When I tried to do that just now I couldn’t set a custom width. I eventually deleted the photo and re-inserted it from my media storage again. Then I was able to adjust it’s width.

I may need to look for an alternative to the WordPress app. More to come…

Update Today #2

It didn’t take long, like ten minutes, for me to discover there are no other real alternatives to the WordPress app on iOS. Maybe if I ask the WordPress folks nicely I can get a copy of the app’s code and make the fixes myself.