Secure testing team - Mar 2006 - Debian Security Analyzer (debsecan)

Hi Florian,
> I''ve hacked something to check installed packages against the
> vulnerability database.
this is nice.

A suggestion: it should not print packages that are in state
"deinstall ok config-files" (at least not by default).

Cheers,
Stefan

Florian Weimer wrote:
> I''ve hacked something to check installed packages against the
> vulnerability database.  It''s similar to the tsck script, but
should
> handle all package annotations correctly.  Most of the logic is
> server-side; debsecan downloads a compressed, release-specific
> vulnerability list.
> 
> Currently, there''s only a darcs repository.  Get it and test it:
> 
>   $ darcs get http://darcs.enyo.de/fw/debian/debsecan/debian debsecan
>   $ python debsecan/src/debsecan --suite sid
> 
> (Or sarge or etch, as needed.)
> 
> Comments and suggestions are welcome.  This tool is still in a very
> early stage, but I guess it''s already pretty useful.
Very nice. You plan to upload the deb soon?

It might be good to either move at least the files debsecan uses to a
debian.org machine, or add a debian.net address for it, so that the url
it downloads from is more under debian''s control.

Could it also list unfixed vulnerabilities?

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20051214/58e1e6f5/attachment.pgp

* Joey Hess:
> Very nice. You plan to upload the deb soon?
First I want to make sure that the data format is adequate.  I''ll know
a couple of days.
> It might be good to either move at least the files debsecan uses to a
> debian.org machine, or add a debian.net address for it, so that the url
> it downloads from is more under debian''s control.
I''m fine with a delegation from debian.org or debian.net (or a CNAME,
if delegation is impossible), but a hard-coded A RR is not acceptable.
IIRC, the debian.org hostmaster is pretty unresponsive -- and pulling
the A record might be necessary if the service becomes too popular.

We could distribute the files over the secure-testing mirrors, though.
(Unfortunately, generating them requires 500+ MB for the package file
mirror, and quite a few CPU cycles.  It''s not a straight translation
of the data/*/list files, I''m afraid.)
> Could it also list unfixed vulnerabilities?
Ah, this was a typo on the server side.  Should be back to normal
again.

I''ve implemented the opposite, so that you can say something like
this:

  # apt-get install $(debsecan --suite sid --format packages --only-fixed)

And you''ll download only new versions of those packages which have
security fixes.

This should also work for the other suites, but all this version
tracking is a bit scary.  (BTW, --only-fixed is the main reason why
the package file mirror is needed.)

I''ve hacked something to check installed packages against the
vulnerability database.  It''s similar to the tsck script, but should
handle all package annotations correctly.  Most of the logic is
server-side; debsecan downloads a compressed, release-specific
vulnerability list.

Currently, there''s only a darcs repository.  Get it and test it:

  $ darcs get http://darcs.enyo.de/fw/debian/debsecan/debian debsecan
  $ python debsecan/src/debsecan --suite sid

(Or sarge or etch, as needed.)

Comments and suggestions are welcome.  This tool is still in a very
early stage, but I guess it''s already pretty useful.

* Stefan Fritsch:
> Hi Florian,
>
>> I''ve hacked something to check installed packages against the
>> vulnerability database.
>
> this is nice.
Thanks.
> A suggestion: it should not print packages that are in state
> "deinstall ok config-files"
Fixed, by skipping packages which are not in the "installed" state.
(I hope this is okay; theoretically, a vulnerable binary of a
half-installed package might be left behind.)

* Moritz Muehlenhoff:
> Florian Weimer wrote:
>> Test reports welcome.  If everything goes well, I''m going to
announce
>> 0.2 to a wider audience.
>
> It''s very nice. But the default display should combine reports for
> individual binary packages or work on source packages.
Source packages are a non-starter because they confuse end users. 8-(
I''m going to implement some kind of aggregation in --format report
mode, though.

I have uploaded debsecan 0.2.  Major changes are:

  * debsecan 0.1 did not report vulnerability status correctly when a
    binary package did not match the name of a source package (a
    rather embarrassing bug, which prompted me to create a proper test
    suite).

  * Thanks to Andreas Barth''s kind support, the vulnerability data is
    now stored on the secure-testing.debian.net infrastructure.

  * A script to create a randomized cron entry is included
    ("debsecan-create-cron").

I have discovered how to deal with pinning etc., but this requires
quite a bit of additional code on the server side.  Implementation
will need to wait after christmas, I guess.

Another problem has come up: If a binary package is removed (say,
libfoo7 is replaced by libfoo8), and the foo source package is fixed,
it''s not clear how to deduce that the "fix" is to remove
libfoo7 (and
not to upgrade it, which is not possible because the archive contains
a newer source package, but no binary package).

Test reports welcome.  If everything goes well, I''m going to announce
0.2 to a wider audience.

Florian Weimer wrote:
> Test reports welcome.  If everything goes well, I''m going to
announce
> 0.2 to a wider audience.
It''s very nice. But the default display should combine reports for
individual binary packages or work on source packages. Right now
there dozens of x.org reports for the same three issues.

Cheers,
        Moritz