headers
Ulf Harnhammar | 13 Jun 2005 23:44
Picon

Goals for Etch?

Do you think we should set any specific goals for the
Debian Security Audit Project to achieve before Etch is
released? Our work so far has shown that we don't need
goals, but perhaps we can achieve even more if we set
some goals (at least #X DSA's published before Etch,
comprehensive audits of syslog() bugs or PHP include()
bugs in lots of packages, other goals?).

// Ulf
Permalink | Reply | 6 comments |
headers
Ulf Harnhammar | 12 Jun 2005 00:34
Picon

After Sarge - setting goals for Etch?

OK,

as everyone knows, Sarge is out now. The Debian Security Audit Project
helped improve the security and quality of that release, especially
regarding setuid/gid programs and /tmp bugs in all kinds of programs
but also in other areas.

Next up is Etch. Do you want to set any goals for the Project
(finding at least X bugs leading to the publication of a DSA before
Etch is released, auditing all PHP scripts in Etch for include() bugs,
other goals) or should we go on as we do? We obviously achieve things
without goals, but if we set goals to work towards we might achieve
more.

What does everyone think?

// Ulf
Permalink | Reply | 0 comments |
headers
Javier Fernández-Sanguino Peña | 14 Jun 2005 22:30
Picon
Favicon
Gravatar

Re: Goals for Etch?

On Mon, Jun 13, 2005 at 11:44:24PM +0200, Ulf Harnhammar wrote:
> Do you think we should set any specific goals for the
> Debian Security Audit Project to achieve before Etch is
> released? Our work so far has shown that we don't need
> goals, but perhaps we can achieve even more if we set
> some goals (at least #X DSA's published before Etch,
> comprehensive audits of syslog() bugs or PHP include()
> bugs in lots of packages, other goals?).

Mmm... Setting a goal of a specific number of DSAs in etch might be too 
much. But how about:

- we would like to do a security review of all the base packages before 
etch (at least two people should look into them)

Rationale: base packages are installed in all Debian systems so we want to 
make sure those are OK before release.

or

- we would like to do a security review of a significant percentage of 
extra/optional packages before etch

Rationale: there are lots of packages in the optional/extra area which are
underused, undermaintained and bug-ridden (yes, including security bugs). 
I've caught up some while doing an automatic /tmp review but we are sure to
find lots of those. We could have DSAs issues for those in sarge and force 
those in etch to be pulled off from the distribution (and maybe spank their 
maintainers too...)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ulf Harnhammar | 17 Jun 2005 01:20
Picon

Re: Re: Goals for Etch?

On Tue, Jun 14, 2005 at 10:30:13PM +0200, Javier Fernández-Sanguino Peña wrote:
> - we would like to do a security review of all the base packages before 
> etch (at least two people should look into them)

> - we would like to do a security review of a significant percentage of 
> extra/optional packages before etch

> - we would like to provide a useful and complete document for all DDs (that 
> might be included in the NM process) that describes how to do a security 
> audit of their source packages and find the "low hanging fruit" with a mix 
> of automatic tools and some sensible questions.
> 
> How does any of these sound like?

They all sound great. Here are some types of bugs that the document could
describe:

* format string bugs with syslog(something, something2)
* fscanf(fp, "%s", buf)
* setting HOME to a 16 kB long value and see if things blow up
* strncat(buf2, buf, sizeof(buf2))
* /tmp bugs
* cross-site scripting

I think those can be easily explained and looked for.

// Ulf
Permalink | Reply | 3 comments |
headers
Ulf Harnhammar | 17 Jun 2005 01:50
Picon

Re: Re: Goals for Etch?

On Fri, Jun 17, 2005 at 01:20:14AM +0200, Ulf Harnhammar wrote:
> * strncat(buf2, buf, sizeof(buf2))

buf[sizeof(buf)] = '\0';  is a bad but common idiom as well. We could
go into more detail and describe that strcpy(), strcat() and sprintf()
sometimes lead to buffer overflows, but then the readers will have to
deal with many false positives.

// Ulf
Permalink | Reply | 1 comment |
headers
Steve Kemp | 17 Jun 2005 20:38

Re: Re: Goals for Etch?

On Fri, Jun 17, 2005 at 01:20:14AM +0200, Ulf Harnhammar wrote:

> On Tue, Jun 14, 2005 at 10:30:13PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote:
> > - we would like to do a security review of all the base packages before 
> > etch (at least two people should look into them)

  Good plan.

> > - we would like to do a security review of a significant percentage of 
> > extra/optional packages before etch

  Ditto.

> > - we would like to provide a useful and complete document for all DDs (that 
> > might be included in the NM process) that describes how to do a security 
> > audit of their source packages and find the "low hanging fruit" with a mix 
> > of automatic tools and some sensible questions.

  This actually seems like the most challenging, and potentially useful
 idea.  If enough maintainers became interested in looking at their
 own packages it would decrease the need for us to bother.

> They all sound great. Here are some types of bugs that the document could
> describe:
> 
> * format string bugs with syslog(something, something2)
> * fscanf(fp, "%s", buf)
> * setting HOME to a 16 kB long value and see if things blow up
> * strncat(buf2, buf, sizeof(buf2))
> * /tmp bugs
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Kemp | 17 Jun 2005 20:39

Re: Goals for Etch?

On Mon, Jun 13, 2005 at 11:44:24PM +0200, Ulf Harnhammar wrote:

> Do you think we should set any specific goals for the
> Debian Security Audit Project to achieve before Etch is
> released? Our work so far has shown that we don't need
> goals, but perhaps we can achieve even more if we set
> some goals (at least #X DSA's published before Etch,
> comprehensive audits of syslog() bugs or PHP include()
> bugs in lots of packages, other goals?).

  Apart from your other suggestions I'm thinking of
 making a small  list of classes of packages which 
 can be done from start to finish.

  I like the idea of covering PHP code, and I think
 that another obvious `class` of packages is apache
 modules.  I've mostly covered the core apache2
 modules already, and not found anything which 
 you can trigger without access to the configuration
 file (ie. root access).

  But there are a fair number of other modules which
 could be examined too.

Steve
--
Permalink | Reply | 0 comments |
headers
Ulf Harnhammar | 17 Jun 2005 21:55
Picon

Re: Re: Goals for Etch?

On Fri, Jun 17, 2005 at 01:50:00AM +0200, Ulf Harnhammar wrote:
> On Fri, Jun 17, 2005 at 01:20:14AM +0200, Ulf Harnhammar wrote:
> > * strncat(buf2, buf, sizeof(buf2))

* char buf[MAXVAL];
  .
  .
  strncat(buf, buf2, MAXVAL);

* gets(buf3);

are two other problems that don't give many false positives, so they're
relevant for the type of lighter audit that I think that document should
aim towards.

// Ulf
Permalink | Reply | 0 comments |

Gmane