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.
