On Mon, Jun 28, 2004 at 02:45:21PM +0100, Steve Kemp wrote:
> On Mon, Jun 28, 2004 at 03:29:23PM +0200, Max Vozeler wrote:
>
> > That sound good, I was thinking to include more information. Trouble is
> > that my script scans only binary packages at this time and the machine
> > I'm doing this on is alreay at 95% of it's disk capacity, so there's not
> > really much room for including source packages.
>
> I have a similar problem, I tried to rebuild X last week with the
> SSP compiler, only to have it die because of lack of disk space. 9
> hours into the compile.
Uh, painful :)
How are the packages doing when compiled with SSP? Did you encounter
any significant problems? I'd love to see SSP enabled in the main gcc
package.
> Getting the information from source packages would be almost trivial,
> although I suspect you'd have a lot of false positives. The only issue
> is having a fast mirror, or all the source handy.
If the script runs multiple vulnerability scanners, it could correlate
the results and give "weight" to sections of code flagged by more than
one scanner. That could help filter the false-positives somewhat.
> > That is, unless there is a mechanism that I could use to automatically
> > track new packages that enter the archive. That would take away the need
> > for a complete mirror and I could just delete the processed packages.
>
> You could scan the section from the end of the DWN perhaps? That
> always has a section with new and noteworthy packages in it.
>
> Failing that you could look at the NEW queue on master if you're a
> Debian developer.
Interesting idea. I remember DWN missing some of my new packages though,
so it may not be reliable enough. Checking the NEW queue directly would
probably be best. I do hope to get there eventually :)
What about wanna-build? I seem to remember another not-yet-DD (Goswin)
using this information, so maybe it's publicly available somewhere? I
think I'll next look into using that if it's possible.
> I've already started work on something very similar, I'll post a
> URL tomorrow or so. I have a system which downlaods and unpacks
> a given package then runs a recursive scan on it.
> I'll post my code soon, any comments or suggestions would be
> appreciated.
Sounds great, I'm looking forward to work with it.
> The hardest part is getting a buildable source - many packages include
> the source in tarballs (eg. Apache) so "apt-get source foo" isn't
> sufficient to download the source and scan it..
Hmm.. now that you say it, couldn't there also be code that shows
vulnerabilites only after some automatic code generation during the
build? There is also the issue of macro expansion that could "hide"
some vulnerable code until it's been pre-processed.
This actually seems like a bit of a tricky problem. Maybe a solution
would be to create some kind of filter in or around gcc to check the
code just as it would normally be compiled.
Cheers,
Max
--
308E81E7B97963BCA0E6ED889D5BD511B7CDA2DC
|
