Reported via secalert: There is an algorithmic complexity weakness in the way the MCS translation daemon handles ranges of compartments in sensitivity labels. When translating a security context that includes a range of categories separated by a period, e.g. "c0.c10", the daemon calls the substitute_range() function to replace the range with an explicit declaration of each category, e.g. "c0,c1,c2,c3,c4,c5,c6,c7,c8,c9,10". The vulnerable logic in this function is shown below (with some lines wrapped for readability): while (tok) { if ((r=strchr(tok, '.')) !=0) { int begin=atoi(&tok[1]); ++r; int end=atoi(&r[1]); for (;begin<end+1;begin++) { tmp=sub; if (asprintf(&sub, "%sc%d,", sub, begin) < 0) { error=1; break; } free(tmp); } } else { tmp=sub; if (asprintf(&sub, "%s%s,", sub, tok) < 0) { error=1; break; } free(tmp); } tok=strtok_r(NULL, ",", &ptr); } The attacker supplies the input string for this function, and the values of 'begin' and 'end' are not checked. Consequently, by supplying an abnormally long range, an attacker can cause the program to remain in the above loop for an extremely long period of time. Since mcstransd is a single-threaded, single-process daemon, it supports only one concurrent request. This weakness allows a local attacker to trivially prevent the daemon from responding to requests for an extended period of time (hours or days). When the mcstrans service is enabled, the system calls upon mcstransd for user logins and the execution of many programs. If mcstransd does not respond, those operations silently hang.
Created attachment 193951 [details] patch attempting to fix problem This is a proposed patch to sanity check the values before using them.
removing embargo
This issue has been addressed in following products: Red Hat Linux Enterprise 5 Via RHSA-2007:0542 available at https://rhn.redhat.com/errata/RHSA-2007-0542.html