ovi wrote:
It's ridiculous. What are you saying ?? If I as a client, don't pay you for
having a stable and secure program you sell me a buggy one???? Not even M$ is
thinking this way anymore, although they continue to sell buggy OS.
There's nothing ridiculous about the cost to the client reflecting the
development costs. Implementing security features takes time and
therefore costs money.
Validating inputs requires effort. Testing for and handling errors
requires effort. Authentication, encryption and lots of other things
which may improve security all require effort.
Depending upon the environment in which the software will be used,
there may or may not be any point in expending that effort.
E.g. a command-line utility which isn't setuid and which is only
accessible by users with shell access may not need to be concerned
with buffer overruns. There's nothing which I can achieve by injecting
shellcode into one of my own processes which I can't achieve by just
compiling/installing and running an equivalent program.
[The situation is different if the user may be blindly feeding
"untrusted" data to the program. In that case, the program is
"accessible" to the creators of such data.]
If you are developing software for commercial publication (the
Microsoft model), then it may be used in a large number of different
environments, and many of those environments will require that the
software is robust against "unexpected" inputs.
But not all software fits this model. A lot of software is bespoke,
i.e. it is developed for a specific client for a specific purpose, and
will only be used in a specific context. It's entirely possible that
it doesn't need to deal with unexpected cases, because you are sure
that the only people who will ever use it won't be deliberately trying
to break it. In that situation, expending additional effort on
security issues is unjustified.
--
Glynn Clements <glynn.clements@virgin.net>
