My blog on secure software engineering

My dayjob involves building secure software. If you have an interest, please see my other blog, Software Engineering Security. I try to write on topics that help everyone respond to vulnerabilities in software.

Leaving my day job

I announced this week that I would be leaving my day job. I plan on spending some time working on the boat in the coming weeks.

It was hard choice and hard to to tell the friends that I've made over the years.

We'll see what the future holds.

Computer security guys

If there are any of you reading this, check out my other blog. I've been writing some articles on software engineering security.

Sailboat electrics

A quick plug for Sailboat Electrics Simplified by Don Casey. I got the book yesterday and I've already learned a lot about what I need to do. I think my circuit diagram still stands (with the addition of a fuse on the charger lead). I'm glad I picked up the book though because it has good advice on wiring and crimp connectors. It's a good idea to buy marine wire that is tinned. I was balking at the expense and was about to run to Home Depot to pick up a spool of 18-2 for my LED strip cabin lights, but I think I'll spend the money on some ancor marine wire.

And the computer vulnerabilities are continuing, so the day job has completely eclipsed the boat building. I may not get to build anything this week and I've got a busy Saturday between neighborhood work and a concert. With luck, Sunday will be quiet and I can get the battery box mounted. I have a plan for that.

CVE-2014-3566 POODLE

Some vulnerability details were released today about the POODLE vulnerability.

That poor dog

I've done some analysis for users of F5's BIG-IP and posted it.

The short story is that POODLE exploits something we've known about for some time. There is the bit about forcing clients to fallback to the older SSLv3 protocol. That's rather clever but not really novel.

If you run a server, you should disable SSLv3. There are lots of ways to do that. Frankly, you should disable TLSv1.0 also and support only TLS1.2 for reasons I blogged about 18 months ago.

The frustrating part is that as a consumer there isn't much you can do about this at all. My version of Safari won't let me disable SSLv3. At least I can't find how to do it. Chrome and FF will probably update themselves eventually.

This has been an interesting year in my field.

Shellshocked

Shellshock is a vulnerability that may allow a remote attacker to execute code on your server. Remote code execution is very bad. It may allow an attacker to retrieve your passwords, add your machine to a botnet or even launch attacks against other machines. These attacks are possible when untrusted user input is passed to a program called bash, something you've probably never heard of before.

BASH is a shell; a program that is an intermediary between you and the complicated parts of a computer. The shell is meant to soften the user interface to the computer, it does automatic path searching, filename expansion, and many other tasks. Bash is meant to be used at the command line, but GUIs are usually considered shells as well. Bash is also used as an intermediary between computer processes; when one process wants to start another process, it often sends the command line to bash, who processes it and executes the new program.

BASH (Bourne Again Shell) was written by David Bourne in 1977. Over the years, we've enhanced bash to be a full fledged programming language, complete with syntax, functions and what we call an environment; the area where variables are stored.

We've even enhanced bash to execute code from the environment.

That's where the problem lies.

In some web application frameworks, the headers of a web request are put into the environment by the webserver. In the shellshock attack, a malicious user submits a request that has headers that look like this:

User-Agent: () { :;} #malicious code goes here

The first important bit is the (), which creates a function. The second important bit is the last part. I've used the # which means a comment, but the attacker could put anything in there and your machine will execute it.

The header is put in the environment by the web server before executing a subprocess to serve a webpage. Bash does it's job and happily executes the malicious code before executing whatever back-end program it is supposed to execute.

The attack shown above works on a particular framework called CGI, but the method of sending untrusted, unsanitized input to a program is not unique and can be exploited in a lot of ways.

In many ways, this attack is worse than April's heartbleed. Remote code execution is far worse than mere information leakage. However, this attack is used against servers, so the average user won't see the attack.

My day job was shellshocked today.


I suspect I'll be shelled tomorrow, too.