Bugzilla Bug 163146

Bump to 0.7.1 please. :)

* Fixed SUID security vulnerability by validating success of seteuid/setreuid,
related security advisories, describing the vulnerability:

    * CVE-2006-2916 - artswrapper
    * CVE-2006-4447 - X.Org

*** Bug 140937 has been marked as a duplicate of this bug. ***

sound/gnome, please you provide an updated ebuild for this

I have a compilation error with dev-scheme/guile-1.8.1-r1, even with use
deprecated discouraged.

@scheme: any idea about that ? 

(In reply to comment #3)
> I have a compilation error with dev-scheme/guile-1.8.1-r1, even with use
> deprecated discouraged.
> @scheme: any idea about that ? 

without the actual error, all I can say is that maybe you need some other flags
as well.

Here it is : 

if x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"BSESCM\" -I. -I.
-I.. -I.. -I. -I.. -pthread  -pthread -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include   -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include   -DG_DISABLE_CONST_RETURNS  
-D_BIRNET_SOURCE_EXTENSIONS -march=athlon64 -O2 -pipe -DG_DISABLE_CHECKS
-DG_DISABLE_CAST_CHECKS -fno-cond-mismatch -Wall -Wmissing-prototypes
-Wmissing-declarations -Wno-cast-qual -Wno-pointer-sign -Wpointer-arith
-Wredundant-decls -Wmissing-noreturn -ftracer -finline-functions
-fno-keep-static-consts -MT bsescminterp.o -MD -MP -MF ".deps/bsescminterp.Tpo"
-c -o bsescminterp.o bsescminterp.c; \
        then mv -f ".deps/bsescminterp.Tpo" ".deps/bsescminterp.Po"; else rm -f
".deps/bsescminterp.Tpo"; exit 1; fi

[lots of warnings]

bsescminterp.c: In function 'signal_closure_marshal':
bsescminterp.c:651: error: 'scm_catch_body_t' undeclared (first use in this
function)
bsescminterp.c:651: error: (Each undeclared identifier is reported only once
bsescminterp.c:651: error: for each function it appears in.)
bsescminterp.c:651: error: expected ')' before 'signal_marshal_sproc'
bsescminterp.c:652: error: too few arguments to function 'scm_internal_cwdr'

[again lots of warnings]

this is in the "shell" subdirectory.

[ebuild   R   ] dev-scheme/guile-1.8.1-r1  USE="deprecated discouraged elisp
networking nls regex threads -debug -debug-freelist -debug-malloc"


I really have no clue on how to fix that :/

the page http://beast.gtk.org/download seems to imply that guile-1.6 is needed.

ok, if upgrading doesnt work, we need to backport the patch. i had a quick look
and this should do the job:

http://svn.gnome.org/viewcvs/beast/trunk/launchers/suidmain.c?r1=2875&r2=4022&view=patch

thanks stefan for the help, but older version are unfortunately affected by bug
#131751 (and most likely guile incompatibilities also)

I've commited 0.7.1 to the tree, this one depends on guile 1.6*, so I've
pmasked it to not cause up/downgrades of guile.


in guile-1.8 ebuild there are those lines : 

# Guile seems to contain some slotting support, /usr/share/guile/ is slotted,
but there are lots of collisions. Most in /usr/share/libguile. Therefore I'm
slotting this in the same slot as guile-1.6* for now.
SLOT="12"


so perhaps if scheme wants to help there, by either taking care of the b0rkage
that has caused guile bump or by slotting it properly...



I've only pmasked beast 0.7.1, feel free to pmask older versions also as imho
they are broken.

(In reply to comment #8)
> so perhaps if scheme wants to help there, by either taking care of the b0rkage
> that has caused guile bump or by slotting it properly...

what borkage are you referring to that I could fix? I'd love to slot guile-1.8
separately, but I'm not sure it's possible.

> what borkage are you referring to that I could fix? I'd love to slot guile-1.8
> separately, but I'm not sure it's possible.


bah I've not managed to compile beast with guile 1.8. Try it, it's in the tree
under pmask, you're probably much more able than I am to deal with guile.

I've tried it. The beast developers have their work cut out for them I think.

fixes for beast to compile with guile-1.8 which will be included in the next
release:
http://bugzilla.gnome.org/show_bug.cgi?id=364464

Any news on this one?

Thanks marijn for the help here, beast 0.7.1 should be fine now, 

Adding arches as I suppose 0.7.1 will have to go stable and older versions will
have to be removed.

Thx Alexis. Updating whiteboard.

TEST: test -x "/usr/bin/bsescm-0.7.1"
Failed to verify installation of executable: /usr/bin/bsescm-0.7.1
make[1]: *** [check-installation] Error 1
make[1]: Leaving directory
`/var/tmp/portage/media-sound/beast-0.7.1/work/beast-0.7.1/shell'
make: *** [check-recursive] Error 1

I assume the check should be disabled.

[ebuild  N    ] media-sound/beast-0.7.1  USE="mad -debug -static"

Back to ebuild for now. Alexis please provide an updated ebuild.

very annoying beast ;)

  26 Mar 2007; Alexis Ballier <aballier@gentoo.org>
  +files/beast-0.7.1-noinstalltest.patch, beast-0.7.1.ebuild:
  Dont test if files are installed as they are not at the time we run src_test

(In reply to comment #18)
> very annoying beast ;)
> 
>   26 Mar 2007; Alexis Ballier <aballier@gentoo.org>
>   +files/beast-0.7.1-noinstalltest.patch, beast-0.7.1.ebuild:
>   Dont test if files are installed as they are not at the time we run src_test

 So I cc arches again.

x86 stable

Thx Alexis and Christian for the quick response.

Created an attachment (id=114669) [details]
compile-failure on ppc

Doesn't compile on ppc.

hmmm which linux-headers version do you have ?
In which file is SIGTRAP defined ?

(In reply to comment #23)
> hmmm which linux-headers version do you have ?
=sys-kernel/linux-headers-2.6.17-r2

> In which file is SIGTRAP defined ?
/usr/include/asm/signal.h

Ok I've been able to track and reproduce this error by compiling a cross
toolchain and reading cpp output (ouch), it seems that there is a problem in
glib headers : 

/usr/include/glib-2.0/glib/gbacktrace.h

line 55 (glib 2.12.11): 
#else   /* !__i386__ && !__alpha__ */
#  define G_BREAKPOINT()        G_STMT_START{ raise (SIGTRAP); }G_STMT_END
#endif  /* __i386__ */


but this file never includes signal.h on those non x86{,_64} nor alpha arches.

while this could be fixed by including signal.h in any file using G_BREAKPOINT,
I tend to think that's it's a glib bug.


what do you think, should I just patch beast to resolve this security issue
asap and then let the gnome team fix that or wait for a fix from the gnome team
?

Thx Alexis.

Since this appears to be suid root I would prefer a fix asap and the let the
gnome ppl fix their error afterwards.

then lets go : 
  30 Mar 2007; Alexis Ballier <aballier@gentoo.org>
  +files/beast-0.7.1-signalheader.patch, beast-0.7.1.ebuild:
  Include signal.h to workaround glib not including it causing compile
  failures on ppc

(In reply to comment #27)
> then lets go : 
>   30 Mar 2007; Alexis Ballier <aballier@gentoo.org>
>   +files/beast-0.7.1-signalheader.patch, beast-0.7.1.ebuild:
>   Include signal.h to workaround glib not including it causing compile
>   failures on ppc

Thanks, ppc stable.

I've never used BEAST but fail to see how you're going to escalate privileges
unless you find another vulnerability in BEAST.

hlieberman/Sound/gtk/Security do you know of any way of using this to gain root
privileges without another vuln?

sound or gnome: could someone explain why this app need setuid? Is it really
necessary?
according to this: http://security.linuxtoday.com/developer/2004030900926NWGNRL
It's just to get a -20 priority... I really don't see the point in doing this
:/ Is it a kind of safety net to prevent jitters in case the box get
overloaded? 

please advise.

I don't personally use beast; but I assume, based on past experience with
people using sound systems like JACK, that it is setuid root so that it can set
itself to SCHED_FIFO (or SCHED_RR).  There are workarounds for those to not
need root; maybe Gentoo already does it for JACK?  If so, beast could be
modified to use that, or maybe just configured to use it.

200704-22, thanks everybody. Sorry for the delay.