76 buffer[y]=pt[x]; //
ISS X-Force is reporting the problem as "improper bounds checking of the changevalue parameter in libcgi.h." It can be exploited by supplying a very long value to the changevalue parameter. C compiler problems
I feel it's also important to pass along what is potentially a much more serious problem that may be under the radar of many C programmers. Right at the top I want to make it clear that I have not had a chance to personally confirm how widespread this problem may be, but it has the potential to be very serious. Info Security Magazine's Security Wire Digest Vol. 4 No. 89 reports that some researchers are saying GNU's C compiler, and possibly other popular compilers, are routinely removing some function calls from code when they optimise the code for better performance. In short, the compiler views this security-centric code as wasted lines, since it doesn't relate directly to core functionality. Problem is, some of these features, such as steps taken to remove passwords or other sensitive information from memory, can be critical security elements. When this occurs, even the most security-conscious, careful programmer may have vital security features removed by the compiler itself without his or her knowledge. Joseph Wagner posted a detailed explanation of this problem. Part of his posting includes a detailed example of how this problem occurs. This threat isn't due to a bug in the software, and what Wagner has posted isn't an exploit, just a demonstration of what can occur. After the code, he concludes, "In the above example, the optimising compiler removes the 'memset' function as part of 'dead store removal' optimisation. The optimising compiler realises that 'memset' writes to 'Password' but 'Password' is never again read; hence, it is removed as part of the 'dead store removal' optimisation. A programmer could erroneously think that his code is secure, even though the securing code -- 'memset' -- is removed from the compiled code." In SecurityFocus, Florian Weimer says, "As discussed on BugTraq, this is not a bug in GCC, but a programming error." That is, this is a design flaw, rather than a coding mistake. A related posting from Linus Torvalds (certainly no slouch when it comes to C programming) in a gcc.gnu.org discussion thread discusses the general dangers of code optimisation by GCC. All in all, I consider the sources of this compiler problem to be credible and am recommending that anyone using C compilers, especially GCC, take a serious look at this reported risk, since it could pose a security threat to the work of any C programmer. Applicability
The LibCGI problem lies specifically in Lib CGI 0.1. The Bugtraq report claims this affects Slackware Linux, Debian Linux, and RedHat Linux. A detailed description of how to exploit this vulnerability is available on the opennet.ru page that contains the original report. As far as the potential optimisation threat posed by C compilers, the only specific report I have seen relates to the most recent version of GCC, but there are strong suggestions that this problem exists in other compilers. Since this is not a programming error but a "feature" that was put into compilers as a way to speed up the final code, it's likely to be found in other compilers, too. Risk level
Several sites rate the risk posed by the LibCGI buffer overflow as high. I've found no formal risk rating yet about the report that C compilers are disabling security features during optimisation and not telling users, but this could be a serious problem, especially if it is found to exist in other versions of GCC and other compilers. I don't see any reason to suppose this sort of faulty optimisation would be limited to C compilers, let alone any specific publisher's product. Mitigating factors
A properly deployed intrusion detection program should be able to identify an attack using the LibCGI buffer overflow. As far as the general threat from C compilers, at this point I don't have enough details to make any assessment of the actual level of threat or how widespread it is, let alone determine any mitigating factors. Fix
As of Dec. 4, 2002, Symantec reported that its security team hadn't been notified of any official vendor patches to address the Lib CGI vulnerability. Security Focus Online reports, "An untested, unsupported patch has been made available by 'dong-h0un U.'" This appears to refer to the code contained in the original Russian Web site report on this vulnerability. Regarding the C compiler optimisation problem, Joseph Wagner has posted a gcc.gnu.org report on problem report 8537 which details a workaround for a specific password optimisation problem, as well as offering some general comments about a possible patch. I was unable to find any postings from C compiler publishers addressing the reported optimisation threat. There haven't been any proposed fixes of which I'm aware, other than the one suggested by Mr. Wagner. Final word
Although CGI scripts themselves aren't inherently insecure, they must be written with great care to be kept secure. This is a known programming concern, but a flaw in an underlying C library would make the question of how well the application is written moot. Sometimes it's difficult for me to tell how many readers are affected by some of these vulnerabilities. Obviously, this is a serious threat if you're using the library, especially since the person who found the problem has published a demonstration of how to exploit the vulnerability. The question is, just how many people are actually using this particular libcgi.h C library? Since it's free, there really aren't any records available of how often it's been downloaded. Regarding the reported optimisation problems of some C compilers, this is the strangest threat I've encountered recently because it isn't due to sloppy programming by the developers, and certainly not any malicious intent on anyone's part. Rather, this threat is due to the very effort that was so carefully made to optimise performance. The development process is so hideously complex that unforeseen factors can take a real toll on security.
Have your say instantly in the
Tech Update forum. Find out what's where in the new Tech Update with our
Guided Tour. Let the editors know what you think in the
Mailroom.
Tech Update forum. Find out what's where in the new Tech Update with our
Guided Tour. Let the editors know what you think in the
Mailroom.
