Salut, Alistair,
On Mon, 23 Jun 2008 13:03:33 +0100, Alistair Crooks wrote:
> In software engineering (as opposed to the "rewrite it because I can't
> understand it" clueless lemming spree that is being espoused in some
> places), most errors occur in places where the code was last changed.
That may well be but is not an accurate assumption and certainly
doesn't contribute to our debate.
> Does libarchive have a comprehensive set of regression tests to make
> sure that no bugs have crept back in? Or a test suite at all?
Yes. Please have a look at the "test" subdirectory of the code.
> I would certainly hope that the bugs had been fixed upstream. But
> that doesn't alter the fact that there were exploitable bugs, and so
> my confidence in this software is less than it was. Not just
> exploitable bugs - "potentially to even execute arbitrary code" bugs.
This is pure nonsense. Following this argumentation, we would need to
pull most of our programs from the repository. At least a large
fraction of them already had exploitable security problems, and many of
them even had more than 3.
libarchive is relatively young code, the project appears to have
started in February 2004. But that doesn't mean we have to consider it
written by morons simply because it has had a couple of security
problems.
Also, do you know how various different security problems can lead to
arbitrary code execution? A lot of people have invested a lot of effort
in making it possible to execute code in stack overflows, heap
overflows, re-used signal handler vulnerabilities, double frees,
special types of race conditions and various other occasions. I would
find it presumptuous to claim that one has never written code which was
prone to one of these.
But as easily as they might have slipped in they are fixed. Looking
over the code contained in the libarchive repository, it doesn't seem
to be of such an exceptionally low quality that we should consider it
to be full of security holes even after those you mentioned have been
fixed. Like I said, it doesn't look like a systematic problem to me.
> Please remind me again when this code was audited, and by whom.
Tim Kientzle himself has done some auditing of the code, and Colin
Percival has done the same auditing producing the 3 CVEs you found.
On the other hand, we depend on GNU Tar and pax heavily for our code.
Are you sure these have been audited to the appropriate level?
Especially our pax appears to be so unimportant that it is not even
mentioned as an audit target. I'm not sure this is such a better base
for security assumptions.
Tonnerre
Attachment:
signature.asc
Description: PGP signature