A serious vulnerability has been found in the CGI C libraryLibCGI(libcgi.h), which is used widely by UNIX and Linux programmers. Some serious security concerns have also recently been raised about C compilers themselves.
Symantec reported that “improper bounds checking” is the cause of a LibCGI vulnerability, and that the flaw could allow an attacker to gain Web server process privileges to a system. The original report was posted to BugTraq and a Russian Web site, both of which describe the problem as a “remote frame pointer overwrite vulnerability.” The latter report carries a detailed, if somewhat cryptic explanation of the problem (English is obviously a second language for the writer), which the author says is located in line 76 of Include/libcgi.h:
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 optimize 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 optimizing compiler removes the ‘memset’ function as part of ‘dead store removal’ optimization. The optimizing compiler realizes that ‘memset’ writes to ‘Password’ but ‘Password’ is never again read; hence, it is removed as part of the ‘dead store removal’ optimization. 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 optimization 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.
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 optimization 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.
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 optimization 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 optimization would be limited to C compilers, let alone any specific publisher’s product.
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.
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 optimization problem, Joseph Wagner has posted a gcc.gnu.org report on problem report 8537 which details a workaround for a specific password optimization 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 optimization threat. There haven’t been any proposed fixes of which I’m aware, other than the one suggested by Mr. Wagner.
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.
I’d like readers to tell me whether this was a useful report, from the standpoint of how many of you are using this library. Post a message in the discussion below if you believe your systems are affected by this flaw.
Regarding the reported optimization 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 optimize performance. The development process is so hideously complex that unforeseen factors can take a real toll on security.