Bugzilla Bug 78111

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 an attachment (id=48793) [edit]
openmotif-2.1.30-xpm.diff

Created an attachment (id=48793) [edit]
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 an attachment (id=48861) [edit]
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 an attachment (id=49373) [edit]
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 an attachment (id=49418) [edit]
openmotif-2.1.30-xpm2.diff

Created an attachment (id=49418) [edit]
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 [edit] 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 an attachment (id=50242) [edit]
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 an attachment (id=51203) [edit]
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 an attachment (id=51206) [edit]
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 ;)

stable on ppc64

Stable on ppc.

sparc stable.
btw, repoman complains about on DEPs of the ebuilds that use motif-config (2.1.30-r8 & 2.2.3-r2).

Created an attachment (id=51415) [edit]
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 alpha.

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