Calls to PR_FormatTime not checking return value

NEW
Unassigned

Status

()

Core
General
10 years ago
5 months ago

People

(Reporter: Sunil Mohan Adapa, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nse:meta], URL)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.16) Gecko/20080702 Iceweasel/2.0.0.16 (Debian-2.0.0.16-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

Comment 1

10 years ago
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&regexp=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.
(Reporter)

Comment 3

10 years ago
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.

Comment 4

10 years ago
Lacking a specific threat, I'm going to open this up and move it to Core/General.
Assignee: wtc → nobody
Group: core-security
Component: NSPR → General
Product: NSPR → Core
QA Contact: nspr → general
Version: other → Trunk
Whiteboard: [sg:investigate]
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

9 years ago
Whiteboard: [sg:investigate] → [nse:meta]
You need to log in before you can comment on or make changes to this bug.