Re: [Savannah-hackers-public] ViewVC 1.1.26

[Amin Bandali]

Jeffrey Walton writes:

> On Mon, Aug 17, 2020 at 10:33 AM Amin Bandali <bandali@gnu.org> wrote:
>>
>> Jeffrey Walton writes:
>>
>> > The Savannah website uses ViewVC 1.1.26. It looks like ViewVC is a
>> > couple of years out of date.
>> >
>> > The latest versions are 1.2.1 and 1.1.28. 
>> > https://github.com/viewvc/viewvc/tags
>>
>> The Savannah server running viewvc installs the viewvc package from the
>> repositories of the distro it uses, which is almost always a few
>> versions behind the latest upstream.  We don't typically build and
>> install software from source (as opposed to available distro package),
>> unless there is a very good reason to do so.
>
> It seems like running old software is fairly toxic. We know server
> comprimises most often occur due to stale software. Specifically,
> software that is out of date by 30 days or more.
>
> ViewVC has fixed at least two vulnerabilities since 1.1.26.
>

I only see one (issue #211 on their tracker) affecting 1.1.26, which was
assigned a low severity [0].  Further, the vulnerability is in a feature
that is disabled by default, including on the Savannah server running
viewvc.

[0]: https://github.com/viewvc/viewvc/security/advisories/GHSA-xpxf-fvqv-7mfg

Thus, as I see it, the Savannah server running viewvc is not currently
affected by any publicly-known vulnerabilities in the viewvc version it
is running.

>
> GNU server compromise has happened in the past:
> https://news.slashdot.org/story/10/11/30/2134203/gnu-savannah-site-compromised.
> Whatever patch model is being used, it is not working. Learn from the
> past mistakes.
>
> Jeff

Here is a better link:
https://www.fsf.org/blogs/sysadmin/savannah-and-www.gnu.org-downtime

The attack was possible due to a SQL injection bug in Savane, the forge
software developed and used by Savannah.  I imagine the Savannah servers
were running the latest version of Savane at the time.  Yet they were
still compromised.  Thus, your example does not really support your
argument.  Also, do keep in mind that new versions/releases are
inevitably how bugs get introduced in software.  What guarantee is there
that the newest version does not have new bugs?  In most pieces of
software developed today, none (see below).

Also, I think you fail to realize/notice the countless possible attacks
that were/are thwarted all through the years, thanks to (or despite)
using the current software installation model of relying on security
fixes in distro packages.  Debian and other large distros are generally
pretty good at patching vulnerabilities in the software they package.

In closing, bugs happen.  Programmers are humans, which by nature make
mistakes every now and again.  Sometimes grave ones, but nonetheless
mistakes.  The best way of eliminating bugs would be to have clear
requirement specifications for the software at hand, and use formal
verification techniques to verify the implementation against the
specifications.  Unfortunately, as of now, this is rather costly and
nearly no free software projects do so.  I hope that will change at some
point.

signature.asc
Description: PGP signature