Affected version : openmotif 2.2.3(not got 2.2.4,so not test in
xfocus (http://www.xfocus.org) have discovered multiple vulnerability in
openmotif libUil library. details following:
1: libUil.so diag_issue_diagnostic buffer overflow
202 void diag_issue_diagnostic
203 ( int d_message_number, src_source_record_type
204 int l_start_column, ...)
207 va_list ap; /* ptr to variable
length parameter */
208 int severity; /* severity of message */
209 int message_number; /* message number */
210 char msg_buffer; /* buffer to construct
211 char ptr_buffer[buf_size]; /* buffer to construct
212 char loc_buffer; /* buffer to construct
213 char src_buffer[buf_size]; /* buffer to hold source
293 va_start(ap, l_start_column);
295 #ifndef NO_MESSAGE_CATALOG
296[1.1] vsprintf( msg_buffer,
297 catgets(uil_catd, UIL_SET1, msg_cat_table[
298 diag_rz_msg_table[ message_number ].ac_text),
299 ap );
301[1.2] vsprintf( msg_buffer,
302 diag_rz_msg_table[ message_number ].ac_text,
303 ap );
[1.1][1.2] call vsprintf will cause buffer overflow if ap is user-support
data,so if one local or remote application which used this library may
cause execute arbitrary code .
2: libUil.so open_source_file buffer voerflow
621 open_source_file( XmConst char *c_file_name,
622 uil_fcb_type *az_fcb,
623 src_source_buffer_type *az_source_buffer )
626 static unsigned short main_dir_len = 0;
627 boolean main_file;
628 int i; /* loop index through
include files */
629 char buffer;
632 /* place the file name in the expanded_name buffer */
634[2.1] strcpy(buffer, c_file_name);
636 /* Determine if this is the main file or an include file. */
638 main_file = (main_fcb == NULL);
[2.1] like above
Ccing lanius so that he knows about it, we still need to design a patch.
Also we must determine if lesstif is also affected.
Created attachment 74595 [details, diff]
patch fot bugs
patch ready and working, ebuild is on a way :)
> patch ready and working, ebuild is on a way :)
THERE IS SOMETHIG WRONG IN THIS PATCH, DO NOT USE IT.
reparing in progress...
Created attachment 74616 [details, diff]
new patch, this one is working for sure.
Sorry for any problems
Thx for the patch. Lanius, please check and apply.
sorry, i currently have no possibility to upload anything to cvs, can you please do it for me
the patches attached seem identical, if the first one is broken the second one must be as well?
aqu, what is wrong with the first one?
the first one misses two commas, the second one has them
ahh, so it does :)
yeah, it was my stupid error, sorry about that :)
openmotif-2.2.3-r8 committed, as requested.
Arches, please test and mark stable. thx
This will require to ship lesstif-0.94.4 since the new openmotif uses motif-config, is that correct? (otherwise it blocks).
if you bump it this way you also have to mark motif-config, openmotif-2.1.30-r13, lesstif-0.94.4 and lesstif-0.93.94-r3 stable. i think that is no problem since they all have been around a long time and the only change is to use motif-config.
alternatively you could bump openmotif-2.2.3-r3 instead of openmotif-2.2.3-7.
this packages are stable on ppc64 now:
amd64 done and btw... please fix those QA issues.
There's problem with digest in that package....
Stable on ppc, hppa.
Karol: I cannot reproduce that problem, are you still seeing it?
as a little remark, when writing the GLSA, we might want to write it together with emul-linux-x86-xlibs (bug 116481).
what about the x86 team? i currently have no possibility to commit anything.
oh, thx for the headsup. sorry, my fault - forgot to add x86 :(
seems ready for glsa
arm ia64 and mips should mark stable to benefit from GLSA
Is the quoted text in Comment #0 the full report? It only
seems to mention the first usage of a fixed size buffer directly
following its declaration, and is missing all cases when it's
declared anywhere else but the current function; or when
declaration and usage are too far apart. Just for example, in
629: char buffer;
634: strcpy(buffer, c_file_name);
...these two are listed in the problem URL, but...
680: strcpy (buffer, c_file_name);
...(executed when opening an include file specified by absolute
path name... exact same problem) is not.
As a minor nitpick, the patch in comment #4 replaces `strcpy()'
If the source pointer points to a string longer than the max length
argument, `strncpy()' will not be '\0' terminate the result (in
other words this needs to be done manually), meaning it will run
into whatever comes next in memory until a '\0' character is reached.
(Personally I'd advise against `strncpy()' in this place though,
because there is a slim chance the truncated path may refer to an
existing (but wrong) file which may lead to very confusing error
Created attachment 75850 [details, diff]
Tavis, could you have a look ?
lanius, is it possible for you to create another bump, this time with the other patch (comment #30) and with a workaround for the blocking issues found in bug #117458? If thats ok, please do it, thx.
Taviso / Tigger / Solar / Vapier please look into this.
commited the new patch, i don't know of a way to fix the blocker
So this looks ready for GLSA...
Should probably be published as a GLSA update to GLSA 200512-16...
lanius: shouldn't the patch also be pushed to a 2.1.30-r14 release ?
amd64: how do you stand wrt emul-linux-x86-xlibs ?
(In reply to comment #38)
> amd64: how do you stand wrt emul-linux-x86-xlibs ?
Updated app-emulation/emul-linux-x86-xlibs-2.2.2 is on the mirrors and in cvs
OK, now we just need to be sure if this doesn't also need a 2.1.30-series bump. lanius ?
removing amd64 from cc, we've already done our job ;)
i don't know, whoever posted the patch please check
kloeri said he would take care of this.
kloeri, some news on this ?
What it the status of this bug now ? [stable] or [ebuild] ?
Added the patch to openmotif-2.1.30-r14. Sorry about the delay.
Finally closing this bugger ... feel free to reopen if you disagree.