A message received at security@gentoo.org From: Ulf Harnhammar <metaur@operamail.com> Date: Fri, 10 Mar 2006 16:32:13 +0100 Subject: cURL tftp:// URL Buffer Overflow cURL tftp:// URL Buffer Overflow There is a buffer overflow in cURL when it fetches a tftp:// URL with a size of >66000 characters. The URL must start with "tftp://", then a valid hostname, and then another slash. The bug affects cURL versions 7.15.2, 7.15.1 and 7.15.0. <snip more details> Ulf provides the following patch: --- curl-7.15.1_UNPATCHED/lib/tftp.c +++ curl-7.15.1/lib/tftp.c @@ -271,7 +271,7 @@ /* If we are downloading, send an RRQ */ state->spacket.event = htons(TFTP_EVENT_RRQ); } - sprintf((char *)state->spacket.u.request.data, "%s%c%s%c", + snprintf((char *)state->spacket.u.request.data, 512, "%s%c%s%c", filename, '\0', mode, '\0'); sbytes = 4 + (int)strlen(filename) + (int)strlen(mode); sbytes = sendto(state->sockfd, (void *)&state->spacket,
liquidx: please attach an updated ebuild to this bug if nescessary - do not commit anything to portage at this time, this bug is currently confidential.
Adjusting status
Embargo set to Monday 20th
3 days till disclosure, still no ebuild
Created attachment 82532 [details, diff] curl-7.15-libtftp.patch
Created attachment 82533 [details] curl-7.15.1-r1.ebuild stable series
Created attachment 82534 [details] curl-7.15.2-r1.ebuild ~unstable series
Adding arch security liaisons. curl-7.15.1-r1 could be committed direct to stable on 2006/03/20 if you confirm it's stable on each of your arches.
tested on ppc64. it's ok to commit directly to stable.
x86 looks good to go
Looks good on hppa
Looks good on ppc.
I'm substituting blubb for this bug. Both versions work on amd64. Tested with both curl's test-suite plus my printer's tftp server.
This is public now (7.15.3 has been released) http://curl.haxx.se/docs/adv_20060320.html
Looks good for sparc, sorry for the delay but i'm usually off on weekends for some much needed air & rest.
The issue is now public, opening. I think solar will commit the ebuild soon, alpha still needs to stable
*** Bug 126942 has been marked as a duplicate of this bug. ***
The patch looks ok on Alpha too.
Ok I'll commit the ebuild .15-r1 to stable on the arches that gave feedback. No reason to keep the .2 so I'll pump a .3 in the tree for ~arch users.
Everything is in the tree now. curl-7.15.1[0]: arm ia64 mips ~ppc-macos s390 sh curl-7.15.1-r1[0]: alpha amd64 ~arm hppa ~ia64 ~mips ppc ~ppc-macos ppc64 ~s390 ~sh sparc x86 curl-7.15.3[0]: (M) ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc-macos ~ppc64 ~s390 ~sh ~sparc ~x86
Ready for GLSA
Could someone please clarify the following a little bit, so that we don't state the wrong arches in the GLSA? "libcurl 7.15.1 and 7.15.2 contain code that prevents this code from being executed on architecures where a struct is not of the same assumed packed size it has on x86, thus they are not vulnerable. For exact details on this, please review the code and patch." [from http://curl.haxx.se/docs/adv_20060320.html] This appears to be the relevant part of the code I think: /* * The TFTP code is not portable because it sends C structs directly over * the wire. Since C gives compiler writers a wide latitude in padding and * aligning structs, this fails on many architectures (e.g. ARM). * * The only portable way to fix this is to copy each struct item into a * flat buffer and send the flat buffer instead of the struct. The * alternative, trying to get the compiler to eliminate padding bytes * within the struct, is a nightmare to maintain (each compiler does it * differently), and is still not guaranteed to work because some * architectures can't handle the resulting alignment. * * This check can be removed once the code has been fixed. */ if(sizeof(struct tftp_packet) != 516) { failf(conn->data, "tftp not supported on this architecture"); return CURLE_FAILED_INIT; }
GLSA 200603-19 thanks everyone
Stable on mips.
