On Wed, 2003-01-01 at 04:46, peleus wrote:
> Having said that, you can get into a more specific discussions of
> the security attacks that software programmers are responsible for and how
> they can prevent them. If a library the programmer uses is flawed, is it
> his software's flaw or the libraries flaw? Is the programmer responsible
> for all the libraries his code includes? These type of specific
> definitions define whether software is "secure". Security is a relative
> measurement.

I think a fault in library is always the fault of it, not the software
that uses it. It does anyway reflect badly on the software itself, so
verifying safe usage of a library is a good idea.

For libraries that you have to use and auditing would be too time consuming
(eg. libc) you can still try to use it safely by not using functions that
could be dangerous (eg. glob()) and not allowing parameters that could be
dangerous (eg. large integers, to avoid overflows). vsftpd did this pretty
nicely by wrapping all external library calls and doing sanity checks to
them.

If the library is needed only for a small part of the operation of whole
software, it could be isolated in separate non-privileged process. I don't
trust SSL libraries, so I just assume they're flawed and give them a
somewhat safe playground.

Code also tends to break at incapable hands, so if I go through the effort
of auditing some library, I'll specify in documentation what versions I
consider safe. Auditing newer versions become simpler then if you can just
diff it against a known safe version.

[ reply ]