Bugzilla Bug 68857

TITLE:
WindowMaker Unspecified "WMGLOBAL" Vulnerability

SECUNIA ADVISORY ID:
SA12961

VERIFY ADVISORY:
http://secunia.com/advisories/12961/

CRITICAL:
Less critical

IMPACT:
Unknown

WHERE:
Local system

SOFTWARE:
WindowMaker 0.x
http://secunia.com/product/4132/

DESCRIPTION:
A vulnerability with an unknown impact has been reported in
WindowMaker.

The vulnerability is caused due to insufficient validation of font
specifications in "WMGLOBAL".

SOLUTION:
Update to version 0.90.0:
ftp://windowmaker.org/pub/source/release/WindowMaker-0.90.0.tar.gz

PROVIDED AND/OR DISCOVERED BY:
Reported by vendor.

Can we get some arch testing for the windowmaker-0.90.0 ebuild?
It's curently KEYWORDS="~ppc ~sparc"

x86, sparc and alpha have windowmaker-0.80.2-r2.ebuild marked stable
ppc, ppc64 and amd64 are on windowmaker-0.80.2-r4
mips has never marked any version as stable

windowmaker-0.90.0 appears to only have been added to the tree yesterday 
and with so little details coming from upstream the chances of calling it 
stable are probably slim to none.
Perhaps if we could atleast get our arches on ~arch for this package so testing can underway that would be great.

More details on how it is vulnerable would be good...

Arches: please test and mark "~" as a first step toward stable-ization :)

Here is a bit more info from the ChangeLog.

- Added a check that only %d is used in a font specification in WMGLOBAL and at
  most once for each font in a fontset (eliminates a possible security exploit)

Looks like a privilege escalation through format string issues. Rating "B1?".

alpha, amd64, mips, ppc64 : please test and KEYWORD as "~" so that we can start getting bug reports on this... and get it stable one day.

~alpha keyworded.

0.90.0 amd64 testing

Testing arch's on windowmaker-0.91.0 would be great as well.  (Basically, the
first 0.9X.0 release had some bugs on some platforms.)

0.91.0 testing too

windowmaker-0.90.0 and windowmaker-0.91.0-r1 marked ~mips.

gnustep herd : do you think it's ready for stable ? Is there outstanding bugs
that need fixing first (if, so please list them as blockers of this bug).

We can't sit on this one for too long.

I've problems using this on ppc64, as libffi doesn't compile, but this is only
needed, if I USE="gnustep". So gnustep could be added to use.mask and I could
add the ~ppc64 keyword.

Please let me know, if I should do that or if I should wait until gnustep is useable.

I opened this bug for gnustep on ppc64: bug #72258

Markus

"gnustep" should definitely not be added to your use flags unless you're
feeling a bit adventurous, atm ;-)

However, windowmaker-0.91.0 has been quite stable for me on ppc and x86.  The
only issues I've come across are some focusing issues directly related to
GNUstep interaction with WindowMaker, so this wouldn't be a concern for most.

All arches should test on 0.91.0, and not 0.90.0, as 0.90.0 was quite bug
ridden wrt NETWM support.  Arches please test the latest revision, currently at
0.91.0-r1, in case any of your users do what to try out GNUstep.  No file
location changes will (likely) appear after this revision w/o a good reason.

windowmaker-0.91-0.r1 seems to have KEYWORDS="~x86 ~ppc ~sparc ~amd64 ~mips",
so it looks like we just need alpha and ppc64 as well to cover the 0.80* series
ebuilds.

Let's try to mark windowmaker-0.91-0.r1 stable...
Target KEYWORDS="x86 ppc sparc alpha ppc64 amd64 ~mips"

Arches : please test and mark stable if you can.
Alpha and ppc64 should try to mark ~ first.

stable amd64... fafhrd: please check the versions of the gnustep-base/*
packages I marked stable to see if there is reason I should've picked a
different version that I was unaware of...

I also took the liberty of adding /etc/X11/dm/Sessions/wmaker.desktop so it
shows up in gdm's list of sessions.

eradicator, for gdm in recent gnome's I thought it's /usr/share/xsessions?

0.91.0-r1 doesn't look to be stable on ppc64, least if you want to use the
preferences app :-)

0.90.0 however is working and I intend to mark that stable shortly.  Currently
working through the forest of gnustep deps

I was about to remove the file locations alterations dependant on the use of
the "gnustep" USE flag, and then create a rev version bump for testing with
this flag, hoping to speed up this security issue.  It looks like amd64 went
stable already for the original 0.91.0-r1 ebuild (with the gnustep USE flag),
so for platforms where GNUstep is quite unlikely to build/work atm, such as
ppc64 (no idea if it can/will work here), could those platforms add "gnustep"
to their own use.mask?  Does this sound reasonable?

This scenario is just kind of odd, because WindowMaker can be configured to be
tightly coupled to a GNUstep based installation, but it doesn't have to be
(and, good to note, it usually isn't, for most), and I wouldn't want to slow
down fixing a security issue just 'cause GNUstep isn't happy. ;-)

To follow up to comment #16, the reason prefs doesn't work here is the default
menu references /usr/GNUstepSystem/Applications/WPrefs.app/WPrefs which doesn't
exist.  The correct path is /usr/GNUstep/System/Applications/WPrefs.app/WPrefs

seemant: I added it locally to the /etc/X11/dm/Sessions, and it showed up in my
sessions list for gdm-2.6.0.4-r1

I'm guessing one of those is deprecated... and knowing my luck, I used the
deprecated one... I'll double check.

I tested windowmaker-0.91.0-r1 on ppc and it seems to work fine, but when
trying to commit for this bug, repoman complains of IUSE.invalid (profile), bad
RDEPENDS for ~mips on gnustep-base/gnustep-env and the xinerama patch is 26K.

Thanks!

marked 0.91.0-r1 stable on x86

Marked ppc stable.

Stable on sparc (with gnustep useflag masking).  Let us know when the gnustep
people feel confident with stablizing it and we'll unmask.

Sent email upstream for more information

From WindowMaker team :

----------
The impact is that if you have your configuration files (most specifically
~/GNUstep/Defaults/WMGLOBAL) world writable, someone could put one of
those string format exploits in there. So, I guess it's nothing
alarming...
----------

So it's a local root in case you screw up your configuration badly. I think I'm going to drop that one as invalid.

There is a local root if you set /etc/init.d files world writeable too, and it's not a vulnerability.

It's not even a local root, it's a local user exploit. This is hardly a
vulnerability, so it will be closed without GLSA.

Keeping the bug open to track stable marks

Stable on alpha.

added dependency, which blocks me from marking it stable on ppc64.

Time to close this... This is not a vulnerability anyway. I still hope ppc64
will be able to mark it stable someday, but security doesn't care, in fact.