Feeds:
Posts
Comments

Archive for May, 2009

While working on my Google Summer of Code project today, I came across a bug that pretty much halted my productivity for the day.

Early on in my project, I decided that working with Unicode is hard, among other things. Since I was restricted to using C, I had to find a way to easily manipulate Unicode stuff, and I came across GLib (I’m not even entirely sure how, I think I just remember other projects using it, and decided to look it up.)

Not only did it have Unicode handling stuff, it also provides a bunch of convenient things like a linked list implementation, memory allocation, etc. All in a way intended to be cross-platform compatible, since this is the thing that’s used to power Gtk.

I’m not entirely sure how it differs from Apache’s Portable Runtime (APR); maybe it’s even a Not Invented Here syndrome. In any case, I, not suffering from that particular affliction, decided to be lazy and re-use existing code.

For some reason, GLib’s g_slice_alloc() call was failing. For those of you that don’t know what this does, it is similar to malloc() in standard C – it allocates a chunk of memory and returns it to you, so that you can make use of dynamic memory allocation, rather than everything just being auto variables. In particular, it means you can be flexible and allocate as much or as little memory as you need.

So I spent the entire day trying to figure out why my program was segfaulting. Looking at the output of gdb (the GNU Debugger), the backtrace showed that it was crashing at the allocation statement. No way, I thought, that test is so well-tested, it must be a problem with the way I’m using it.

I changed the code to use malloc() instead of g_slice_alloc(), and the program started crashing right away, rather than after four or five executions with g_slice_alloc(). Not exactly useful for debugging.

I mentioned my frustration with C on the Debian Perl Packager Group channel, and a friend from the group, Ryan Niebur took a look at the code (accessible via a public repository). After a bit of tinkering, he determined that the problem was that I was using g_slice_alloc instead of g_slice_alloc0, which automatically zeroes memory before returning it.

It stopped the crashing and my program works as intended. I’m still left totally puzzled as to why this bug was happening, and I’m not sure if malloc isn’t supposed to be used with structs, or some other limitation like that.

But thanks the magic of open source and social coding/debugging, the expertise of many contribute to the success of a single project. It’s such a beautiful thing.

Update: There were a lot of questions and comments, mainly relating to the fact that malloc and friends return chunks of memory that may not have been zeroed.

Indeed, this was the first thing I considered, but the line it happened to be crashing on was a line that pretty much just did g_slice_alloc, rather than any of the statements after that.

For those that are curious, all of the code is visible in the public repository.

I do realize that the fixes that have been made are pretty much temporary and that they are probably just masking a bigger problem. However, I’m at a loss for the issue is. Hopefully the magic of open source will work for me again, and one of the many people who have commented will discover the issue.

Read Full Post »

The problem with secret questions is that they’re not very secretive. Back in the 1990s, it might have been reasonable to assume that information like “What was your first school?” might be secret. However, now, in the days of MySpace and Facebook, and especially Google, it’s fairly easy to find information about people.

A problem with passwords is that people forget them. On the other hand, a problem with other methods of authentication like public key cryptography is that they are not portable. Moreover, the problem with solutions like RSA’s SecurID token is that they can be lost.

Generally, the wisdom for truly secure systems is to combine these various approaches, in what is called Multi-Factor Authentication. Wikipedia describes these as:

However, usually a password is sufficient because, if well chosen, and if the rest of the system is secure, they can provide a reasonable balance between everything. Yes, they do require memorizing, but on the other hand, you’ll never lose it unless you forget it. They are also weak because you can’t know if somebody else shoulder-surfs and catches your password, or has a keylogger installed on a public workstation.

Worse, if you are using an unencrypted wireless network connection such as the one we have at Western, then your data (including your password) travels over-the-air in plaintext. I’ve actually tried sniffing packets using Wireshark over the wireless network, and captured quite a bit of stuff, all without having to log into the system. For those in the know, there is also a secure network, but it’s significantly harder to set up – it uses WPA2 Enterprise – and though Windows XP and Vista both support it, the added cost of setting it up doesn’t seem worthwhile to most people. But all this is the subject of another article.

Because secret questions are often used for password recovery in the event that your password is lost or your account is compromised (by an attacker who missed the option to change your secret question), they are essentially a second password on your account.

Why are two passwords bad? They effectively double the chances that one of them will be cracked; if attackers find that your actual password is too difficult to crack, they might look at your secret question instead. Worse, because the question is considered “public” information (how are you supposed to remember the answer, without being given a question, after all), then attackers have a context for your password.

Imagine having this as your real password. “Hint: It’s the name of your first son.” People then don’t need to know you very well at all in order to figure out your password. Worse, most people will pass this sort of information without knowing it in conversation. Find out what someone’s secret question is? Steer the conversation there. “Got any kids? What’s his name?” etc.

This social engineering is particularly dangerous because while people know their passwords are precious, they are less likely to even remember their secret question and wouldn’t protect that information too much anyway.

Some better systems have opted to verifying e-mail addresses, but then the e-mail account becomes the weakest link. If a user’s e-mail account gets hacked, then the attacker thus has access to all their other accounts through the “Send the password to my e-mail” feature.

There are lots of solutions to this, but I think the lesson learned is that human factors play the largest and most often overlooked part of software design, especially web applications. For software security to improve, programmers and designers need to be a lot more careful – validate all input from forms/parameters, sanitize output that goes to users’ browsers to eliminate Cross Site Scripting (XSS) risks. It’s really just a reminder that a little bit of paranoia can go a long way to protecting the end-user.

Read Full Post »

As energy demand continues to rise, cost-effective delivery of electric power becomes a daunting task.  Many jurisdictions responded by introducing legislation to privatize the power generation industry, so that large networks of systems with multiple different owners could share the load.  As remote power systems add more interconnections, new challenges are emerging related to overall power system stability, particularly in relation to distributed generation as with renewable power sources in the home.

Traditionally, engineers integrated power systems under the assumption that power consumption increases gradually such that operators can simply add generation capacity to meet demand and one can consider the system relatively unchanging with time.  Similarly, operators could compensate for changes in the overall power profile by adding inductors or capacitors to substations depending on the typical load.  For example, a substation supplying power to an industrial mill would consume reactive volt-amperes (VARs) so the local utility would add a capacitor to compensate for the inductive load, in order to preserve voltage regulation.  However, once the mill is no longer operating (for example, at night), the resulting reduction of load causes a rise in the supply voltage, which can be well above the desired voltage.

Flexible AC Transmission Systems (FACTS) are different because, as the name implies, they are flexible: designed to be dynamically adjusting to the power demand and other conditions of power quality.  A basic installation might consist of an operator- or microprocessor-controlled bank of capacitors can consume reactive power when necessary.  The state of the art is to provide continuous switching using power electronic devices, which have a much faster response time than a human operator or even a microprocessor-based control system.  Novel devices even filter harmonic oscillations, which can significantly reduce power flow and cause stability issues.

Optimum usage of current transmission line assets is the most cost effective option available and FACTS devices allow utilities to provide greater power delivery with better system stability and power quality.  It is often prohibitively expensive to build new power lines, so these devices provide a stopgap measure capable of delivering increased capacity while also reducing transmission losses.

This article was taken from a report which I co-authored. It was submitted to ECE3333: Power Systems I, taught by Professor Rajiv Varma at the University of Western Ontario in Spring 2009.

Read Full Post »

Older Posts »