[Secure-testing-team] Bug#566142: sudosh3: "code quality is terrible", says debian-devel ITP review

Simon McVittie smcv at debian.org
Thu Jan 21 15:56:09 UTC 2010


Package: sudosh3
Version: 3.2.0-1
Severity: grave
Tags: security
Justification: during replay, reads up to 8MB into an 8KB buffer

You don't seem to have responded to Adam Borowski's mail wondering why this
package should be in Debian, and commenting on its quality. In particular,
he notes a trivial buffer overflow during replay.

In http://lists.debian.org/debian-devel/2010/01/msg00317.html he writes:
> >  sudosh allows complete session logging of shells run under sudo.
> >  Individual sudo commands are still logged as normal but running a shell
> >  under sudosh records the entire session as well as session timings for
> >  complete playback later.
> 
> Uhm, it appears to be an one-trick pony which tries to replicate what ttyrec
> does, except that it's usage is sharply limited, it spits out several files
> instead of one, and the code quality is terrible.  Just one example:
> 
> In replay.c, it does sscanf("... %i ...", &b) to an int, makes a sanity
> check, rejecting values of b more than 8MB -- comparing it as a _signed_
> value.  Then, it does read(fd, buffer, (size_t)b).  (size_t is unsigned).
> 
> But after a second reading of the code, you don't need to go that far.  The
> check against overflow was for 8MB, and size of the static buffer is 8192
> bytes...
> 
> 
> Also,
> > * License         : Open Software License version 2.0 (non free)
> 
> Is there any need for non-free tools where better free equivalents already
> exist?  Try ttyrec, my termrec, script -t (not as well suited for this
> task), RealLog, nh_recorder or one of many others...

Regards,
    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 793 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20100121/e3b637d8/attachment.pgp>


More information about the Secure-testing-team mailing list