Bugzilla Bug 114234

Title: [xfocus-SD-051202]openMotif-libUil-Multiple_vulnerability  
  
Affected version : openmotif 2.2.3(not got 2.2.4,so not test in  
 openmotif 2.2.4)  
 Product: http://www.motifzone.net/  
  
xfocus (http://www.xfocus.org) have discovered multiple vulnerability in  
 openmotif libUil library. details following:  
  
1: libUil.so diag_issue_diagnostic buffer overflow  
  
Clients/uil/UilDiags.c  
 diag_issue_diagnostic()  
     202 void diag_issue_diagnostic  
     203 ( int d_message_number, src_source_record_type  
 *az_src_rec,  
     204 int l_start_column, ...)  
     205  
     206 {  
     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[132]; /* buffer to construct  
 message */  
     211 char ptr_buffer[buf_size]; /* buffer to construct  
 pointer */  
     212 char loc_buffer[132]; /* buffer to construct  
 location */  
     213 char src_buffer[buf_size]; /* buffer to hold source  
 line */  
 ......  
     293 va_start(ap, l_start_column);  
     294  
     295 #ifndef NO_MESSAGE_CATALOG  
     296[1.1] vsprintf( msg_buffer,  
     297 catgets(uil_catd, UIL_SET1, msg_cat_table[  
 message_number ],  
     298 diag_rz_msg_table[ message_number ].ac_text),  
     299 ap );  
     300 #else  
     301[1.2] vsprintf( msg_buffer,  
     302 diag_rz_msg_table[ message_number ].ac_text,  
     303 ap );  
  
    304 #endif  
     305 va_end(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  
  
Clients/uil/UilSrcSrc.c  
  
    620 status  
     621 open_source_file( XmConst char *c_file_name,  
     622 uil_fcb_type *az_fcb,  
     623 src_source_buffer_type *az_source_buffer )  
     624 {  
     625  
     626 static unsigned short main_dir_len = 0;  
     627 boolean main_file;  
     628 int i; /* loop index through  
 include files */  
     629 char buffer[256];  
     630  
     631  
     632 /* place the file name in the expanded_name buffer */  
     633  
     634[2.1] strcpy(buffer, c_file_name);  
     635  
     636 /* Determine if this is the main file or an include file. */  
     637  
     638 main_file = (main_fcb == NULL);  
     639  
 [2.1] like above  
  
--EOF

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 an attachment (id=74595) [details]
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 an attachment (id=74616) [details]
working patch

new patch, this one is working for sure.
Sorry for any problems

Thx for the patch. Lanius, please check and apply.

lanius: *bump*

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:

x11-libs/motif-config-0.9
x11-libs/openmotif-2.2.3-r8
x11-libs/openmotif-2.1.30-r13
x11-libs/lesstif-0.94.4
x11-libs/lesstif-0.93.94-r3

sparc stable.

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 :(

x86 done

Alpha done.

Cheers,
Ferdy

seems ready for glsa

GLSA 200512-16
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 
`clients/uil/UilSrcSrc.c/open_source_file()'...

    629: char buffer[256];
    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()' 
with `strncpy()'...  
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 
messages).

Created an attachment (id=75850) [details]
UIL patch

Created an attachment (id=75850) [details]
UIL patch

 

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.

assigning.

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...

ppc-macos stable:

x11-libs/motif-config-0.9
x11-libs/openmotif-2.2.3-r8
x11-libs/openmotif-2.1.30-r13
x11-libs/lesstif-0.94.4
x11-libs/lesstif-0.93.94-r4

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.

Hi,
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.