Re: Public disclosure of discovered vulnerabilities
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


sci.crypt archive

Re: Public disclosure of discovered vulnerabilities

From: Andrew Reilly <andrew-newspost@areilly.bpc-users.org>
Date: Wed Jun 08 2005 - 07:34:31 CEST

On Tue, 07 Jun 2005 21:36:05 -0500, Del Cecchi wrote:
> Modern tools and appliances and consumer electronics are typically
> designed so the customer who doesn't read any manual can operate them and
> exercise most of the functions. Why do you think those companies have
> departments of usability consultants.

That doesn't necessarily help, though. Let me give a counter-example:

I read the instruction manual for my microwave oven for the first time,
yesterday (because it had stopped working, and I was looking for
information about fuses.) I've had this unit for about four years, and
one of its main uses is defrosting chicken wings to feed the dogs. Every
so often, maybe one time in twenty, the wings would wind up thoroughly
cooked, rather than warm and raw, even though I believed that I had always
used the same setting. Now I know why this happened: the oven has a neat
"dual cook" feature, where you can enter a power level, then a cook time,
and then another power level and another cook time, and it will perform
both *in sequence*. I had always assumed that such a second set of
settings would just replace the first, and used that assumption to correct
setting entry errors (pressing "power" once too often cycles from "20%"
back to "100%".) I'd always just assumed that the thing's microcontroller
had an intermittent bug, but no: it was a feature. It would have had the
same bad behaviour if it had been coded in Java.

Give it a while, someone will build an "unavoidable" gateway to a denial
of service attack into the standard Java (or, perhaps more likely C#)
standard library, and it'll all be on again.

Scripting languages (anything with an "exec" function, so the lisp family
fit here) are notorious for having holes caused by a confusion between
code and data, all within a secure string and array handling framework.

There are lots of ways to write bugs. Discipline is required everywhere.

One of the big things that C has against it is the amount of "legacy" code
from an era when people were happy with the "this will work if everyone
plays nice" standard, even though we're now in an era of "this must
continue to work in the presence of evil". Rsh would still be a security
problem if coded in Java. Word viruses have nothing to do with
implementation in C.

-- 
Andrew
Received on Thu Sep 29 21:41:17 2005