cURL / Mailing Lists / curl-library / Single Mail

curl-library

ssluse.c patch

From: Gisle Vanem <gvanem_at_broadpark.no>
Date: Wed, 28 Apr 2004 14:49:06 +0200

I tried the RATS tools on ssluse.c.
RATS = "Rough Auditing Tool for Security" available from
http://www.securesw.com/download_rats.htm

It has a vulnerability database for OpenSSL and gave some
recommendations:

ssluse.c:386: Medium: X509_NAME_oneline
ssluse.c:1209: Medium: X509_NAME_oneline
ssluse.c:1233: Medium: X509_NAME_oneline
Allow the function to dynamically allocate the buffer.
If you insist on a fixed buffer, then double check that your buffer is as big
as you specify.

ssluse.c:1144: Medium: ERR_error_string
Use ERR_error_string_n() instead

ssluse.c:1217: Medium: CRYPTO_free
ssluse.c:1241: Medium: CRYPTO_free
Does the memory need to be cleaned before freeing?

--------------

The 'X509_NAME_oneline' warning made sense, but why is it
used in cert_verify_callback()? Only the ret-val is significant
AFAICS from the OpenSSL docs.

I'm not sure about the CRYPTO_free() warning. But I have
a patch for ERR_error_string() and some cpp stuff:

--- CVS-latest/lib/ssluse.c Tue Apr 27 15:56:23 2004
+++ lib/ssluse.c Wed Apr 28 14:32:39 2004
@@ -388,16 +388,13 @@
   return ok;
 }

-#endif
-
-#ifdef USE_SSLEAY
 /* "global" init done? */
 static int init_ssl=0;

 /* we have the "SSL is seeded" boolean global for the application to
    prevent multiple time-consuming seedings in vain */
 static bool ssl_seeded = FALSE;
-#endif
+#endif /* USE_SSLEAY */

 /* Global init */
 void Curl_SSL_init(void)
@@ -1141,7 +1138,8 @@
           return CURLE_SSL_CACERT;
         default:
           /* detail is already set to the SSL error above */
- failf(data, "SSL: %s", ERR_error_string(errdetail, error_buffer));
+ ERR_error_string_n(errdetail, error_buffer, sizeof(error_buffer));
+ failf(data, "SSL: %s", error_buffer);
           /* OpenSSL 0.9.6 and later has a function named
              ERRO_error_string_n() that takes the size of the buffer as a third
              argument, and we should possibly switch to using that one in the

--gv
Received on 2004-04-28