openmotif includes vulnerable libXpm.
Eradicator is it affected by the newer libXpm issue (GLSA 200411-28) also?
I have no idea. I just saw the advisory last night, and it was very vague... I would assume not (don't quote me) because I think they were derived from different codebases...
lanius: Why was the 2.2 series removed from portage?
Patch does not apply cleanly to our openmotif, even if parts of it applying tend to prove we are affected. lanius, eradicator: please have a look, but this seems rather complicated :)
Created attachment 48793 [details, diff] openmotif-2.1.30-xpm.diff
Created attachment 48793 [details, diff] openmotif-2.1.30-xpm.diff Nothing complicated... :) xpm code hasn't changed in a decade, except maybe for some `config.h' stuff added in some openmotif versions... addresses: CAN-2004-0687, CAN-2004-0688 (mostly identical to SUSE patch 51696 and what is used by various other vendors... additionally makes `xpmHashTable' members unsigned)
I'll add that to a revbump in a few minutes. Thanks for the help =)
in cvs: target keywords: alpha amd64 arm hppa ia64 mips ppc ppc64 ppc-macos sparc x86
Could someone doublecheck that openmotif is not also vulnerable to CAN-2004-0914 (GLSA 200411-28). Here is the x.org patch : http://www.x.org/pub/X11R6.8.1/patches/xorg-681-CAN-2004-0914.patch
The CAN-2004-0914 patch probably has to be adapted and applied, too.
Removing arches for now, we probably need a little more patching. bartron: I know it's nothing complicated, but if you could "adapt" the -0914 patch (or whatever equivalent patch you may find) to openmotif too, we'll appreciate the help.
Created attachment 48861 [details, diff] attempt to adapt the CAN-2004-0914 fix Warning! This is my firt large patch ever made and contributed, so tripplecheck this a trillion times. I probably messed it up, but I thought I'd give it a try anyway.
I don't really have time to fix this ATM, but I didn commit a bump that uses this patch, fixes multilib issues, and uses the proper mandir... the only problem is the CAN-2004-0914 patch causes openmotif not to build. Stefan: Can you please look into this? Lanuis: Why did youu punt the 2.2 versions? They have a much better build system... gcc -c -I. -I../../exports/include -I../../exports/include -I../.. -I../../exports/include -I../../imports/x11/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE=500L -D_BSD_SOURCE -D_SVID_SOURCE -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -O2 -pipe -fomit-frame-pointer -I/usr/include/gentoo-multilib/amd64 Xpmcreate.c -o unshared/Xpmcreate.o Xpmcreate.c: In function `XmeXpmCreateImageFromXpmImage': Xpmcreate.c:807: error: label `error' used but not defined Xpmcreate.c: In function `_XmxpmParseDataAndCreate': Xpmcreate.c:2137: error: parse error before "else" Xpmcreate.c: In function `ParseAndPutPixels': Xpmcreate.c:2360: warning: cast from pointer to integer of different size Xpmcreate.c:2363: warning: cast from pointer to integer of different size make[3]: *** [Xpmcreate.o] Error 1 rm -f Xpmscan.o unshared/Xpmscan.o gcc -c -I. -I../../exports/include -I../../exports/include -I../.. -I../../exports/include -I../../imports/x11/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE=500L -D_BSD_SOURCE -D_SVID_SOURCE -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -O2 -pipe -fomit-frame-pointer -I/usr/include/gentoo-multilib/amd64 Xpmscan.c -o unshared/Xpmscan.o Xpmscan.c: In function `XmeXpmCreateXpmImageFromImage': Xpmscan.c:226: error: label `error' used but not defined make[3]: *** [Xpmscan.o] Error 1
I will try again, but chances are high that I'm not successful :-( Is there a good reason not to use the upstream 2.2.4 version?
Jeremy: bug #29388
Apparently the CAN-2004-0914 fix from xorg relies on a "error" label that's not defined in our openmotif, so this requires more adaptation. Bartron, would you like to have a try ?
Created attachment 49373 [details, diff] openmotif_CAN-2004-0914.patch New attempt at patch. The xorg patch has several "{ ... }" --> "do { ... } while(0)" things that have probably nothing to do with security, I removed them. Now it applies and builds correctly.
Created attachment 49418 [details, diff] openmotif-2.1.30-xpm2.diff
Created attachment 49418 [details, diff] openmotif-2.1.30-xpm2.diff xorg patch from comment #?? ported to Motif version of the XPM library (should also work with earlier and later Motif versions with minimum work, not tested yet though...)
[ah...too late]
[or maybe not...] attachment #49373 [details, diff] does not prefix/rename `s_popen', so if a Motif application also links to the external libXpm, it will see two symbols with the same name...
ARRR!!! Patch in comment 16 be not building correctly here: libXm be missing after install. ARRR!!! [...] gcc -c -I. -I../../exports/include -I../../exports/include -I../.. -I../../exports/include -I../../imports/x11/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE=500L -D_BSD_SOURCE -D_SVID_SOURCE -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -O2 -g Xpmcreate.c -o unshared/Xpmcreate.o Xpmcreate.c: In function `_XmxpmParseDataAndCreate': Xpmcreate.c:2144: parse error before "else" make[3]: *** [Xpmcreate.o] Error 1 [...] gcc -c -I. -I../../exports/include -I../../exports/include -I../.. -I../../exports/include -I../../imports/x11/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE=500L -D_BSD_SOURCE -D_SVID_SOURCE -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -O2 -g Xpmdata.c -o unshared/Xpmdata.o Xpmdata.c: In function `_XmxpmGetCmt': Xpmdata.c:374: `dmata' undeclared (first use in this function) Xpmdata.c:374: (Each undeclared identifier is reported only once Xpmdata.c:374: for each function it appears in.) make[3]: *** [Xpmdata.o] Error 1 [...] ARRR!!!
Ghost Pirate: does the patch from comment #17 work better for you ? eradicator/lanius: where are thou ?
Ok, it has been some time since bug #78111 has been discussed. Meanwhile two things have happende: - lesstif-0.94.0 has been released, which completely dropped motif-1.2 support - openmotif-2.2.4 has been released with improved build system. As far as I see the situation, openmotif-2.2.4 should be backwards compatible to 2.1 versions, as long as we just symlink libXpm.so.3 to libXpm.so.2. So I propose: - update openmotif to 2.2.4 with this symlink - update lesstif to 0.94.0 - let both provide virtual/motif again and block each other
Heinrich, This looks like a good idea... But apparently openmotif-2.2.4 only fixes half the Xpm vulnerabilities so don't forget to add CAN-2004-0914 patches...
bartron: what's your oppinion about that?
lanius: If you're going to add 2.2.4 to portage, a few things you should know... openmotif-2.2.4.tar.bz2 (or was it tar.gz) is on the gentoo mirors already. I couldn't find it on upstream's mirrors, so I extracted from the src.rpm. Also, there is a header file missing from the source... something xml related. You'll need to just copy it from the 2.2.3 source to ${FILESDIR} then put it in the correct directory at src_unpack(). I have since deleted the 2.2.4 ebuild I was working on, but hopefully that will save you some time...
ARRR! Patch in Comment 17 be compiling (and be working) o.k. (now that I can actually see comment 17)
added openmotif-2.2.3 with all neccessary patches to portage, please test it, it's currently hard mask, because people have to rebuild their motif apps, because libXm.so.2 has changed to libXm.so.3 and is not binary compatible
Arches: please test openmotif-2.2.23 (don't forget to revdep-rebuild so that broken binaries are rebuilt) and mark stable if it works.
works on x86 and amd64
Why related GLSAs don't have OpenMotif entries?!
... maybe because we discovered that openmotif was affected by that only since January 15 ? If you knew before that time, you should have filed a "vulnerability" bug instead of waiting for us to do so. We rely on the community to report such problems.
stable on ppc64
Stable on alpha.
sparc stable.
A couple of issues with this ebuild. Mostly it works, only 4 problems so far. Ebuild deems virtual bindings files "unneeded files". A large number of users may agree, but in heterogenous networks with lots of different machines and different keyboard layouts they're absolutely essential. Freezing/Disappearing text area in all but one window in NEdit (5.5) with many open windows seems to be back, but should be easy to avoid, if NEdit is built with Lesstif (like Red Hat and Mandrake do). FontSelector (the OpenMotif standard font selection dialog) does not work with OpenMotif built with this ebuild (still investigating this one as the only programs that use this dialog box are commercial ones, where no source code is available. They work flawlessly with libXm.so.3 from SLES and Red Hat even with latest patches though so this looks like a Gentoo specific problem). Patches seem to be incomplete. There are constructs like s += n + snprintf(s, ...); all over the place (where n=length of format string when snprintf retval already includes that and therefore advances s exactly n bytes too far beyond the end of s). Thought this was already fixed in older patch revisions.
Created attachment 50242 [details] screenshot Update: didn't find a patch in google, but the patch in comment 17 seems to fix remaining buffer overflows in xpm routines. The font selector may be another such problem. I have found a program that does not just seg fault on the value returned from the dialog box, but complains, that the font does not exist on my machine. The displayed gibberish (see lower image in attached file) varies every time the same font is selected. Looks like, selected font is grabbed from random, uninitialized memory. Works in Mandrake and Red Hat, and with libXm.so.3 extracted from Suse and Red Hat RPMs on Gentoo, so this should confirm the problem is with the Gentoo patches. Hope it's ok to attach images here, if not, just yell.
> Ebuild deems virtual bindings files "unneeded files". A large number of users may agree, but in heterogenous networks with lots of different machines and different keyboard layouts they're absolutely essential. This are just example files, but i can add them to doc if you want to. > Patches seem to be incomplete. I took the patches from the fedora src rpm.
> ... maybe because we discovered that openmotif was affected by that only since January 15 ? That was the question - why, after more than two weeks since then, `glsa-check -t all` doesn't list this one?
Tobias: you tested the openmotif-2.2.3 ebuild, right ? I don't understand, it appears to have the CAN-2004-0914 patch applied. If I try to reapply the patch from comment #17 it fails... Could you give precise examples in 2.2.3 patched code which are missing a necessary patch ? About your other comments, did the previous openmotif ebuild (2.1.* series) show the same issues or are they new issues brought by the 2.2.3 ebuild specifically ? Evgeny: I think you misunderstand what glsa-check does. It doesn't show you if your current system is affected by any known vulnerability. It just takes the published GLSAs and checks that you have applied all those that are affecting you. We issue GLSAs when the ebuild is ready and stable, not before. So it's quite normal that glsa-check doesn't show openmotif as vulnerable.
Koon: I understand what glsa-check does. Part of the 2004-0914 fixes have been already in openmotif-2.1.30-xpm.diff patch for some time and it's included in openmotif-2.1.30-r6.ebuild. So I'd expect an equivalent of glsa-200410-09.xml (which is for Lesstif) to be there for OpenMotif, too. Another issue: PLEASE, make openmotif-2.2 a different slot than 2.1! They're binary-incompatible.
In fact there are two issues... - One is CAN-2004-0687/0688 (GLSA 200409-34 for X.org, 200410-09 for lesstif) - The other is CAN-2004-0914 (GLSA 200411-28 for X.org, no GLSA yet for lesstif, see bug 78483) This bug was open for Openmotif following publication that OpenMotif was vulnerable to CAN-2004-0687/0688 (see URL above). Patches correcting this were applied to 2.1.30 (see comment #7). Then we realized that maybe OpenMotif was probably vulnerable to the recent CAN-2004-0914, as well as lesstif. We searched for a patch and the Gentoo maintainer to apply it, which took time. We could have released a partially fixed OpenMotif after comment #7, but this doesn't make sense since another vulnerability of the same type was found. We could also have released an OpenMotif GLSA back in October but for that, we had to be aware that OpenMotif included this vulnerability, which we were not. That's why I say that we depend on the community to help us find vulnerabilities. If you knew by then that OpenMotif was vulnerable, you should have opened a bug by then, and we would have issued a fixed package and a GLSA by then. About the SLOT thing... I'm not the maintainer, you should bring your case to Heinrich (lanius). His idea was (I think) to keep the same SLOT and ask people to revdep-rebuild after the upgrade ?
Stable on ppc.
Koon: thanks for clarification. I must've mixed a few things when reading through 30+ comments. Heinrich: regarding SLOT'ting: except for ABI incompatibility (which is by itself, IMHO, worth assigning a SLOT), Motif-2.2 currently is not as stable as 2.1.30 is (BTW, 2.1.31 is available). See http://www.motifdeveloper.com/tips/tip22.html for an analysis. Part of the issues have been fixed since then, but still, 2.2 is somewhat buggy.
arm/hppa/ia64 stable
This is ready for the GLSA... Heinrich, you might want to comment on what Evgeny says before we issue it, but since we are quite late we won't wait for long :) If 2.2 is really that unstable, we could still add back a 2.1.* version after that GLSA, and we'll modify the GLSA so that this new version is considered not vulnerable. But that will be the topic of another bug.
Can't wait any longer, this is GLSA 200502-06 mips / ppc-macos: please mark stable to benefit from GLSA Evgeny: about the SLOTing and the return of the 2.1 branch, you should file another bug and assign it to lanius for comments.
Version 2.2 does not work on macos because of the automake and autoconf versions. The new -collision-protect profile will stable 2.2 but the default profile will need to stick with 2.1.
Well, slotting openmotif is not easy, since openmotif-2.1 and openmotif-2.2 put their headers in the same directory and mwm as well, don't know if there is more. Try to comment out the autoconf stuff and built it on ppc-macos.
Heinrich Wendel: (re: comment 37) Virtual bindings are not example files. Whenever a Motif application starts and does not see '_MOTIF_DEFAULT_BINDINGS' set on it's display, it consults '/usr/X11R6/lib/X11/bindings/xmbind.alias' to map the X server identification string to a filename that it reads and attaches to the current screen's root window for usage by future Motif apps. If they are missing, the same bindings as used on the client machine are used, which is rarely accurate if multiple architectures are involved. Please see Volume 6A and 6B of the O'Reiley Definitve Guides to the X-Window System for more details. (Should I mention SLES and RHEL install those by default?) bartron: ping Koon: (re: comment 39) vanilla openmotif-2.2.3 as is is vulnerable to both vulnerabilities. What that means is if you wanted the patch from comment 17 you'd have to apply the patch from comment 5 first and make sure to add the newly added file to lib/Xm/Makefile.am (2.1 does not need Makefile.am). Code example of missing patch is as follows (example from XpmCrBufFrI.c) [..] for (x = 0; x < num; x++, ext++) { #ifndef VOID_SPRINTF s += 11 + #endif snprintf(s, data_size - (s-dataptr), ",\n\"XPMEXT %s\"", ext->name); #ifdef VOID_SPRINTF s += strlen(ext->name) + 11; #endif [..] } s points to buffer data is written to. after snprintf() call s is supposed to point to new end of s ('\0'). On systems where snprintf() returns void, s is advanced by strlen(ext->name) (length of the '%s' substitute) plus 11 (length of raw format string). On systems where snprintf() returns number of printed characters, like glibc-based ones, s is advanced by the number of characters printed, this includes the length of the raw format string + length of ext->name + length of format string again (the additional +11) again. In the end, you're writing (num*11) characters past the end of whatever 'dataptr' points to. Doesn't look like a very safe thing to do to me. The other issues only appear with Gentoo's libXm.so3 (it's a commercial app that requires libXm.so.3 and 2.1 provides libXm.so.2).
Heinrich: (re: comment 48) Yes, different slot versions should put headers/bins in different directories. An openmotif-config, similar to gcc-config,opengl-config,... would be nice. I'd even say motif-config, to deal with lesstif as well. If you wish, I'll file a new request.
Tobias: good catch... Apparently the patch Heinrich put in portage is not as complete as the patch from comment #17 : Patch in comment #17 (adapted from SuSE) =========================================================== @@ -358,24 +405,24 @@ for (x = 0; x < num; x++, ext++) { #ifndef VOID_SPRINTF - s += 11 + + s += #endif - sprintf(s, ",\n\"XPMEXT %s\"", ext->name); + snprintf(s, data_size - (s-dataptr), ",\n\"XPMEXT %s\"", ext->name); #ifdef VOID_SPRINTF s += strlen(ext->name) + 11; #endif =========================================================== Patch from portage files/openmotif-2.2.3-CAN-2004-0914.patch.bz2 (grabbed from Fedora's source RPM): ----------------------------------------------------------- @@ -365,7 +410,7 @@ #ifndef VOID_SPRINTF s += 11 + #endif - sprintf(s, ",\n\"XPMEXT %s\"", ext->name); + snprintf(s, data_size - (s-dataptr), ",\n\"XPMEXT %s\"", ext->name); #ifdef VOID_SPRINTF s += strlen(ext->name) + 11; #endif =========================================================== Reopening bug... For the others problems (SLOTting, inclusion of Virtual bindings, garbled display) you should open separate bugs (and assign them to lanius) so that they don't get closed when the security issue gets fixed. Heinrich: You should probably replace the Fedora patch by the patch from bartron, it looks more complete...
Evgeny: Can you please open a new Bug and point out how we can accomplish the SLOTing/motif-config thing Koon: the patch from comment #17 does not apply cleanly to openmotif-2.2.3
I'll try to sort things out and build a SuSE-derived patch applying cleanly to 2.2.3. I don't grok openmotif code so if anyone else wants to try, be my guest.
Created attachment 51203 [details, diff] openmotif-2.2.3-CAN-2004-0914-new.patch New CAN-2004-0914 SuSE-derived patch, applying cleanly on 2.2.3 Please double-check it looks clean :) Test compilation in progress...
also openmotif-2.1.30-xpm2.diff does apply fine to openmotif-2.1.30, seems to compile fine, but fails to build and install the libraries because of an error in the libXm code
Patch fails on Xpms_popen, I'll post a new one as soon as I sort it out.
Created attachment 51206 [details, diff] openmotif-2.2.3-CAN-2004-0914-newer.patch Newer patch that works. Applies, compiles and seems to work clean (I lack Motif apps to test).
will test tomorrow, could you do one for openmotif-2.1.30 as well?
lanius: you should test that one, before asking me for another one ;)
works fine here, commited as openmotif-2.2.3-r1, keyworded: ~alpha amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~ppc-macos ~sparc x86
One more time... Arches: please test and mark the very last openmotif-2.2.3-r1 stable
what about a patch for openmotif-2.1.30 now ;)
sparc stable. btw, repoman complains about on DEPs of the ebuilds that use motif-config (2.1.30-r8 & 2.2.3-r2).
Created attachment 51415 [details, diff] openmotif-2.1.30-CAN-2004-0914-new.patch Patch for CAN-2004-0914 / 2.1.30, adapted from openmotif-2.1.30-xpm2.diff, verified compiles ok.
thx, works fine here, commited as openmotif-2.1.30-r7, keyworded: ~alpha amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~ppc-macos ~sparc x86
Stable on ppc-macos.
Stable on mips.
Apparently 2.1.30-r7 still misses alpha keyword.
Alpha fixed.
Ready for a GLSA update, I'll do it tomorrow. This just adds fixed (and better) versions so we can probably do a silent update.
GLSA 200502-07 updated to include the additional and better fixed versions. Not republishing, as the original fix was deemed buggy but sufficient... Feel free to reopen bug is you disagree.
Already stable on hppa