Re: Debian audits (qa, security, rough, performance...)
On Sat, Oct 26, 2002 at 08:55:56AM -0500, Drew Scott Daniels wrote:
> Well seeing as how me and Steve Kemp <skx@tardis.ed.ac.uk> have both
> started related projects I feel that now is a good time to announce and
> ask for help for our projects.
Agreed.
> Steve Kemp is working on a project at http://www.steve.org.uk/Debian/
> which seems to be mainly a security audit and seems to be done by hand
> which is a superior method.
My project is primarily focussed on security issues, and is carried out
by hand in the main. However I've just created a tools page with pointers
to some of the tools you mention, and a 'fuzz tester'.
> I would like to call for there to be an audit team and I would like most
> popular packages to be audited first. Avery Pennarun <apenwarr@debian.org>
> 's "Debian Popularity Contest Results" at
> http://www.debian.org/~apenwarr/popcon/ may be a good place to look for
> figuring out package popularity. Debian-security and Debian-qa may be able
> to help with creating an audit team.
I'd forgotten about the popularity contest; my initial thoughts were that
all packages which are remotely accessable should be looked at first,
along with those 'base packages' which we all know and love.
The popularity contest approach is a good one though.
> I am starting a similar related project at
> https://sourceforge.net/projects/debraudit/ which is a more general audit,
> but only a rough automated audit which may make developers and code
> auditor's jobs easier. My project is considerably less well developed but
>
> I feel will assist audits of Debian code. I would also like to target
> performance and any kind of bugs in my audit project.
I think that performance bugs may be hard to fix, even if simple to report,
so I'd, personally, not mention them.
Other bugs are worth reporting. I know that I've reported a few trivial
ones over the past few days (eg. program `foo` crashes if given a command
line argument of xxxxx... x 3000), these are the kind of things that might
be exploitable if the binary in question is setuid/setgid.
> I too am looking for help, however I am looking for security audit tools,
> users of the tools, and would like help automating rough testing. I know
> some people think rough audits give a false sense of security, however I
> feel that a rough audit is far better than no audit and the more audits
> the better (multiple manual audits by trained/experienced people is the
> best).
I'd be happy to share any interesting results with you, or anybody
else. (Obviously some things can't be publically mentioned until they've
been fixed though)
> splint, rats and other tools are useful.
They look good, I recently been playing with rats and my initial impression
is that it looks good, I like the way it trys to weed out false positives.
> Audit code such as ADL is very useful. ADL is inline audit code for C++.
From my limited examination of ADL it just appears to be pre-condition
and post-condition assertion system for C++, modelled after XP. If it
were to be used it would have to be used globally within the project,
and seems hard to retrofit.
Is my understanding flawed, or is this a fair assessment?
Steve
---
# OnTopic: Hacks .. ;)
www.steve.org.uk/Hacks
Reply to: