User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) Gecko/20080702 Iceweasel/22.214.171.124 (Debian-126.96.36.199-0etch1) Build Identifier: PR_FormatTime seems to have been called many times through out mozilla code without checking for the return value. PR_FormatTime uses strftime to get things done and returns the return value from strftime. When the buffer length passed to strftime is not sufficient it returns 0 and the contents of buffer are not defined (according to glibc man page). The callers are unconditionally using the returned buffer. In many places, a buffer length of 100 is given. This, realistically, can be crossed. For example: "LANG=te_IN date +%c |wc -c" gives "81". Luckily, te_IN is using arabic numerals. If regional numbers were used (as some localizers argued for) it would have crossed 100. Marking security just in case (I don't know the usual policy). Sorry for the trouble if its a non-bug. Reproducible: Always
Do you have a list of the sites you're concerned about? You filed this as an NSPR bug, but it appears that NSPR is doing the correct thing and the bug would really be in the various callers.
See http://mxr.mozilla.org/mozilla/search?string=PR_FormatTime+*%5C%28®exp=on&case=on&find=%7Bmanager%2Cextensions%2Cmodules%2Cnetwerk%2Cnss%2Flib%7D&findi=&filter=%5E%5B%5E%5C0%5D*%24&hitlimit=&tree=mozilla for a list of calls to PR_FormatTime in mozilla. I agree with Benjamin that this is not an NSPR bug, but rather bugs should be filed against numerous other products/components. Perhaps this bug can serve as an umbrella bug for the others.
Yes, yes, I thought too that NSPR does it right. I simply filed it under NSPR because I didn't know what else to do with so many callers. Benjamin, I don't have any sites that I am concerned about. I just came across this when viewing the code.
Lacking a specific threat, I'm going to open this up and move it to Core/General.
Assignee: wtc → nobody
Component: NSPR → General
Product: NSPR → Core
QA Contact: nspr → general
Version: other → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.