Interpreters, Open Source, and Security vulnerabilities (was Re: [TriLUG] OT: www.hexblog.com - a fix for the WMF vulernability.)

[Tanner Lovelace]

On 1/4/06, Rick DeNatale <rick.denatale at gmail.com> wrote:
> Well, I come from a background where we wrote Smalltalk and Java VMs,
> so "programming an interpreter" meant just that.  I haven't heard many
> people talk about programming the x interpreter, instead of writing an
> x program where x might be BASIC, perl, ruby, ...  unless they were
> actually writing or changing an X interpreter.

Ok, so it looks like we have a difference of terminology, then. :-)

> The point of the distinction which came from earlier in this thread
> was that the vulnerablilty here doesn't come from having an
> interpreter involved, but from having executable code involved in the
> voting machine code, and particularly in the auditing process, on the
> removable device.

While you are correct in that it could be done without an interpreter,
the simple facts are that because it was an interpreter it was VASTLY
EASIER to accomplish.  The intermediate format accubasic code is
translated to is simply a tokenized ascii format so modifying the memory
card from it is much simpler than if it were compiled.

In addition, interpreters are still *forbidden* by FEC regulations, so
it shouldn't be there at all.

For more information, btw, about just what was done, please see
the full report at http://www.blackboxvoting.org/BBVreport.pdf .
This report appears to be from this past summer, before the
most recent demonstration in Leon County, FL, but it is
EXTREMELY enlightening and explains just how the machine
was hacked and why having interpreted code made it much easier.

> Interpreters tend to get bad raps for security and other things which
> aren't justified.  I used to expend a good portion of energy
> disabusing customers of conventional wisdom about "interpreted"
> languages.

I agree.  Modification of the program on the memory card could have
easily been avoided and/or detected if they had just used a simple
checksum.  Unfortunately, they did not, which opened the door to
program modification (which was made much easier by the fact
that the code was interpreted and not compiled).

[...]

> In some ways, users of compiled languages might be lulled into a
> lowered state of vigilance for security vulnerabilities.  As the
> golfers say, "It ain't the arrow, it's the indian."  Security is in
> the hands of the craftsman more than the tools.

Agreed.

> And in the case of, say a voting machine, where a dishonest company
> MIGHT want to put in a backdoor to tilt the playing field, we need to
> be careful not to let the salesman assure us that we don't need to
> audit the system, no matter WHAT the underlying technology is, or
> whether the alleged source code is available or not.

Agreed.  You really should read the link I posted previously
to the article entitled "President Nader ..." on just how easy this
would be!

> I don't remember how many recall the "obfuscated voting machine"
> contest that was covered on /. a few years back.  The winner was
> portable C code which cooked the results, even only doing this on the
> date of the election.  Even with the source code, the knowledge that
> it was crooked, AND a hint that it involved a buffer overflow, the
> source code looked perfectly reasonable, to the extent that it
> required stepping through the code with a debugger to find which line
> of code changed the result, and then a good bit of head scratching to
> figure out how it was doing it.

Link, please?

> And, as an attempt to claim this as OT, I hope that some find this is
> a valuable discussion of the real interactions between security,
> trust, language implementations and features, and source availability.
>
> I'm a computer geek with enough gray hair to know that I shouldn't
> trust any single layer for protection against accidental or
> intentional harm.

Absolutely.

> Peace, brother!

And to you too.

Cheers,
Tanner
--
Tanner Lovelace
clubjuggler at gmail dot com
http://wtl.wayfarer.org/
(fieldless) In fess two roundels in pale, a billet fesswise and an
increscent, all sable.