A libcurl buffer overflow has just been reported to BugTraq
(see http://www.securityfocus.com/archive/1/391042 ). It concerns a stack-
allocated buffer in the NTLM authentication code that can be overflowed by a
malicious server. The suggested fix is to allocate the buffer on the heap,
which translates into a patch like this:

Index: lib/http_ntlm.c
===================================================================
RCS file: /cvsroot/curl/curl/lib/http_ntlm.c,v
retrieving revision 1.36
diff -u -r1.36 http_ntlm.c
--- lib/http_ntlm.c 7 Dec 2004 23:09:41 -0000 1.36
+++ lib/http_ntlm.c 21 Feb 2005 23:48:00 -0000
@@ -103,7 +103,6 @@
     header++;
 
   if(checkprefix("NTLM", header)) {
- unsigned char buffer[256];
     header += strlen("NTLM");
 
     while(*header && isspace((int)*header))
@@ -124,7 +123,12 @@
          32 (48) start of data block
       */
 
- size_t size = Curl_base64_decode(header, (char *)buffer);
+ size_t size;
+ unsigned char *buffer = (unsigned char *)malloc(strlen(header));
+ if (buffer == NULL)
+ return CURLNTLM_BAD;
+
+ size = Curl_base64_decode(header, (char *)buffer);
 
       ntlm->state = NTLMSTATE_TYPE2; /* we got a type-2 */
 
@@ -134,6 +138,7 @@
 
       /* at index decimal 20, there's a 32bit NTLM flag field */
 
+ free(buffer);
     }
     else {
       if(ntlm->state >= NTLMSTATE_TYPE1)

The strange part about the advisory is the note "Initial vendor
notification - No response". That doesn't sound like the Daniel we all
know and love on this list. If a bug reported here has a two hour
turnaround time between being reported, discussed and a fix checked in
(along with an associated test case, of course), then Daniel's having
a slow day ;-) They obviously didn't try very hard to make contact.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved