Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Securing open source web apps with static analysis

Posted: 11 Dec 2013 ?? ?Print Version ?Bookmark and Share

Keywords:server? OpenSSL? Secure Sockets Layer? SSL? Linux?

The Apache web server, sendmail, and OpenSSL all make profligate use of C runtime library dynamic memory allocation. Unlike Java, which performs automatic garbage collection, dynamic memory allocation using the standard C runtime requires that the application itself handle potential memory exhaustion errors. If a memory allocation fails and returns a NULL pointer, a subsequent unguarded reference of the pointer is all but guaranteed to cause a fatal crash.

In the Apache source file scoreboard.c, we have the following memory allocation statement:

ap_scoreboard_image =
??calloc(1,sizeof(scoreboard) + server_limit *
??sizeof(worker_score *) + server_limit *
??lb_l imit * sizeof(lb_score *));

Clearly, the size of this memory allocation could be substantial. It would be a good idea to make sure that the allocation succeeds before referencing the contents of ap_scoreboard_image. However, soon after the allocation statement, we have this use:

ap_score_board_image->global = (global_score

The dereference is unguarded, making the application susceptible to a fatal crash. Another example from Apache can be found in the file mod_auth_digest.c:

entry = client_list->
table[idx]; prev = NULL;

while (entry->next){/* find last entry */ prev = entry;

entry = entry->next;


The variable entry is unconditionally dereferenced at the beginning of the loop. This alone would not cause the analyser to report an error. At this point in the execution path, the analyser has no specific evidence or hint that entry could be NULL or otherwise invalid. However, the following statement occurs after the loop:

if (entry) {

By checking for a NULL entry pointer, the programmer has indicated that entry could be NULL. Tracing backward, the analyser now sees that the previous dereference to entry at the top of the loop is a possible NULL reference.

The following similar example was detected in the sendmail application, in the file queue.c, where the code unconditionally dereferences the pointer variable tempqfp:

errno = sm_io_error(tempqfp);

sm_io_error is a macro that resolves to a read of the tempqfp->f_ flags field. Later in the same function, we have this NULL check:

if (tempqfp != NULL) sm_io_close(tempqfp,

In addition, there are no intervening writes to tempqfp after the previously noted dereference. The NULL check, of course, implies that tempqfp could be NULL; if that were ever the case, the code would fault. If the pointer can never in practice be NULL, then the extra check is unnecessary and misleading. What may seem harmless sloppiness can translate into catastrophic failure under certain conditions.

In sendmail, there are many other examples of unguarded pointer dereferences that are either preceded or followed by NULL checks.

The final example in this category comes from OpenSSL, in file ssl_lib.c:

if (s->handshake_func == 0) {

Shortly thereafter, we have a NULL check of the pointer s:

if ((s != NULL) && !SSL_in_init(s))

Again, the programmer is telling us that s could be NULL, yet the preceding deference is not guarded.

Buffer underflow
A buffer underflow is defined as an attempt to access memory before an allocated buffer or array. Similar to buffer overflow, buffer underflows cause insidious problems due to the unexpected corruption of memory. The following flaw in file queue.c in sendmail was discovered by static analysis:

if ((qd == -1 || qg == -1) && type != 120)
??else {

??switch (type) {
??case 120:
????if (bitset(QP_SUBXF,

?First Page?Previous Page 1???2???3?Next Page?Last Page

Article Comments - Securing open source web apps with s...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top