The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: KSR[T] Advisory #004: printfilter / groff / lpd (fwd)

John Goerzen wrote:
> 
> Are we vulnerable to the below? 


> From: "KSR[T]" <ksrt@dec.net>
> To: BUGTRAQ@NETSPACE.ORG
> 
>                  The first problem is that
>                  some of these filters use /tmp as scratch space,
>                  which opens up a symlink attack for file creation
>                  and file overwriting.  ( lpd is running as user
>                  bin, group root )

On debian systems, no program from groff package is installed setuid;
all are run as normal user.
libgroff defines its own temporary file function which uses mkstemp(3),
which fails if filename exists.
Therefore I think that groff programs aren't exposed to "symlink attack
on temporary files".


> 
>                  The second problem is that a lot of the helper
>                  applications were not built with security in mind.
>                  One example of this is groff.
> 
>                  There are several troff/groff 'requests' that allow
>                  commands to be executed.  The result is that anyone
>                  with a simple understanding of troff can send
>                  a troff document to a remote server, causing the
>                  remote server to execute arbitrary commands as
>                  user bin, group root.

As above, groff package on debian doesn't install any setuid program.
But anyway the problem exists, and is a well known problem.
troff contains some directive (like .sy) that allow direct execution of
commands simply included in the data document (not as user bin.root as
stated in the quoted post).

>From a first glance to sources, I've seen only the .sy directive that
directly passes commands to system(3). From a quick test I've seen that
the .sy is not disabled, and I think that we should disable it on our
version of troff.

Does anyone knows of any other directive that could be so dangerous to
user's files?

I will release groff with the fix for stable and unstable.

I also would like to take a look at Erik's patches, if someone can help
me finding the diff file for source from this and previous version of
groff for redhat 4.2 . I would even need instructions on how to open a
source rpm package (I've heard that normal unix tools aren't enough).


> 
>                It is important to note that other operating systems
>                may use a print filter that will use applications
>                like troff.  They are just as susceptible to attack as
>                the operating systems listed above.
> 

Yes, THIS is a problem.
Anyway, why print filters must be run as privileged user?
Can't those filters be run as a user reserved only for this purpose?



> Erik Troan <ewt@redhat.com> has put updated RPMS online at:
> 
> ftp://ftp.redhat.com/updates/4.2/i386/groff-1.10-8.1.i386.rpm
> ftp://ftp.redhat.com/updates/4.2/i386/rhs-printfilters-1.41.1-1.i386.rpm
> 


Cheers,
Fabrizio
-- 
| fpolacco@icenet.fi    fpolacco@debian.org    fpolacco@pluto.linux.it
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .