[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: security audit of package toppler

On Tue, Nov 04, 2003 at 12:14:47AM +0100, Bill Allombert wrote:

> There were talk back in August of people willing to perform security
> audit of packages including set[ug]id binaries.

  That was largely a result of my suggestion I think, after I started
 looking over random packages.

  I've been thinking of doing this in a more public way recently
 allowing the results of "safe" packages to be viewed, and allowing
 votes on packages - but I never seem to find the time to create the
 database and support pages necessary.
  I'm also wary of making things too public on the offchance that
 something gets public before it should.  That's already been a problem.

> So, I would like to know if one of you is willing to review toppler.

  I had a look at the two versions to hand, toppler 0.96 in stable,
 and toppler-1.0.3 in unstable.  Neither of these are installed setuid
 upon my system.

  The stable version has several exploitable overflows inside it,
 which appear to have been fixed in the unstable version.

  The unstable version appears to be mostly OK.  I'm not going to
 say completely OK because I've not looked at it closely yet, but I
 see nothing *immediately* wrong.

  All the unbounded operations I looked at appeared safe assuming that
 the allocation of memory succeeds - and I believe that the standard
 C++ "new" function will throw an exception if this isn't the case.
 (I've not kept up with C++ at that level, so I could be mistaken here).

  Command line arguments are handled sensibly, and environmental
 variables are handled properly which have been the most comment source
 of errors.

  The only thing I'd want to look at properly are the file handling, if
 the game is setgid it may be possible to read/write to files a normal
 user shouldn't be able to access.

> Toppler could be made setgid games, but this was disabled with security
> concern with older version. Newer version have security fix, but I would
> like the advice of a security expert before reenabling it.

  Looking over the code the only difference would be a highscore
 function, right?  Could it be made setgid it's own group instead of

# Debian Security Audit Project

Reply to: