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.
This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 18:57:35 PST