132 bytes, application/x-perl
136 bytes, text/plain
4.02 KB, text/html
8.40 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 Build Identifier: Mozilla/5.0 there are heap based buffer overflows triggered by "send page" and then sending the email. the overflow is at least in 1.7 and nightly from 3.sep. the fucked code is in nsMsgCompUtils.cpp mime_generate_attachment_headers one of the overflows is triggered by: if (*s == ' ') PUSH_STRING("%20"); one char consumes 3 bytes of memory, while only 2 are allocated. to reproduce try to send as page "data:text/html;,A_LOT_OF_SPACES. the other buffer overflow is triggered by sending long http urls containing ' ', not clear which code fucks it. btw, the macro PUSH_STRING is quite unsafe and i suggest it checks whether there is enough space left. Reproducible: Always Steps to Reproduce: will attach testcases. Actual Results: the heap is fucked up Expected Results: the heap is not fucked up
Created attachment 157874 [details] /cgi-bin/long2.pl put in cgi-bin, access it, click on the link then choose "send page" and send the email.
Created attachment 157875 [details] /cgi-bin/long.pl put in cgi-bin, access it, put web server on localhost:1234 which should serve anything, send the page as email.
mscott, can you take a look? /be
Created attachment 157934 [details] [diff] [review] Proposed patch - changes PL_strcpy with nsCAutoString bug 257314 was fixed by changing PL_strcpy with nsCAutoString, so this patch does the same. the risk from regression is low, the performance hit is minimal. the only potential problem may be memory leak in this: return PL_strdup(buf.get()); couldn't find the definition of nsCAutoString
Created attachment 158152 [details] [diff] [review] updated version of the fix I took Georgi's original patch and did the following: 1) removed the tabs 2) changed the nsCAutoString to an nsCString 3) I also did a review on the code to make sure each .Append call had the same arguments as the old push string call. 4) Note that many (but not all!) of these changes are inside of a GENERATE_CONTENT_BASE ifdef which we don't defined during the build so some of it isn't actually executed. There are still more cases of PUSH_STRING that could probably be converted over to using the string APIs in this file.
Comment on attachment 158152 [details] [diff] [review] updated version of the fix See: http://bugzilla.mozilla.org/show_bug.cgi?id=258005#c6 for details
fixed on the aviary 1.0 branch and the trunk. We should probably let this bake for a couple days before landing for 1.7.x?
+ nsCString buf(""); no need for the "" argument, strings are empty by default
If the string-expanding PUSH_STRING("%20") is inside the ifdef, then the buffer overrun must be somewhere else. Does this really fix it?
Checked "updated version" into the 1.7.2 branch Fixes the html testcase linked above, can't test the cgi-bin testcases right now. I'm concerned similar PUSH_STRING() problems lurk in mime_generate_headers: > /* Add a bunch of slop for the static parts of the headers. */ > /* size += 2048; */ > size += 2560; If the "slop" had to be increased once there's no guarantee we haven't added new headers since. Or that it was even right to begin with.
dveditz: i agree that other occurences of PUSH_STRING should be fixed also in the same simple way. per your previous comment, i believe the c++ stuff fixes the overflow in both testcases as evidence suggests. btw, are there any docs which explain the methods and usage of basic NS* classes?
> are there any docs which explain the methods and usage of basic NS* classes? For nsString <http://www.mozilla.org/projects/xpcom/string-quickref.html> <http://www.mozilla.org/projects/xpcom/string-guide.html> but they may be outdated and incomplete.
at least that second link is pretty up-to-date.
(In reply to comment #11) > Checked "updated version" into the 1.7.2 branch > I found this patch is not in 1.7 branch. Is there anything wrong?
I found this patch is in MOZILLA_1_7_3_RELEASE branch but not in MOZILLA_1_7_BRANCH. Should we check it into MOZILLA_1_7_BRANCH so that we can have it in mozilla 1.7.4 and later?
Yes, please put this on the 1.7 branch.
It is still not on the MOZILLA_1_7_BRANCH for 1.7.5.
Both Tracy and I tested the html testcase using 1.75 Windows 20041216 - I tested using 1.75 Mac 20041216-09. verifying fixed after discussion with dveditz.
(note: fix checked into 1.7 branch by mkaply on 12/15)