173853 - flawfinder warnings in nsNativeAppSupport[OS2|Ph|Win].cpp

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[Stephen P. Morse]

Heikki ran flawfinder (http://www.dwheeler.com/flawfinder) on Mozilla 1.0.1 
branch.

flawfinder found 13 warnings in nsNativeAppSupportWin code (3714-3726). Go 
through that list and for each warning:

* If it is false positive, comment here why it is not an issue
* If it is a real issue, make patch for it here and let's get them checked in

In addition to checking the branch, also check the trunk.

3714) xpfe/bootstrap/nsNativeAppSupportOS2.cpp:481 [2] (buffer) strcat: does not 
check for buffer overflows. Consider using strncat or strlcat. Risk is low 
because the source is a constant string.

3715) xpfe/bootstrap/nsNativeAppSupportOS2.cpp:788 [4] (buffer) strcpy: does not 
check for buffer overflows. Consider using strncpy or strlcpy.

3716) xpfe/bootstrap/nsNativeAppSupportOS2.cpp:808 [4] (buffer) strcpy: does not 
check for buffer overflows. Consider using strncpy or strlcpy.

3717) xpfe/bootstrap/nsNativeAppSupportOS2.cpp:916 [4] (buffer) sprintf: does 
not check for buffer overflows. Use snprintf or vsnprintf.

3718) xpfe/bootstrap/nsNativeAppSupportOS2.cpp:993 [4] (buffer) strcpy: does not 
check for buffer overflows. Consider using strncpy or strlcpy.

3719) xpfe/bootstrap/nsNativeAppSupportOS2.cpp:1122 [4] (buffer) sprintf: does 
not check for buffer overflows. Use snprintf or vsnprintf.

3720) xpfe/bootstrap/nsNativeAppSupportOS2.cpp:1707 [4] (buffer) strcpy: does 
not check for buffer overflows. Consider using strncpy or strlcpy.

3721) xpfe/bootstrap/nsNativeAppSupportPh.cpp:119 [3] (buffer) getenv: 
Environment variables are untrustable input if they can be set by an attacker. 
They can have any content and length, and the same variable can be set more than 
once.. Check environment variables carefully before using them.

3722) xpfe/bootstrap/nsNativeAppSupportPh.cpp:137 [3] (buffer) getenv: 
Environment variables are untrustable input if they can be set by an attacker. 
They can have any content and length, and the same variable can be set more than 
once.. Check environment variables carefully before using them.

3723) xpfe/bootstrap/nsNativeAppSupportPh.cpp:139 [2] (buffer) strcat: does not 
check for buffer overflows. Consider using strncat or strlcat. Risk is low 
because the source is a constant string.

3724) xpfe/bootstrap/nsNativeAppSupportWin.cpp:460 [2] (buffer) strcat: does not 
check for buffer overflows. Consider using strncat or strlcat. Risk is low 
because the source is a constant string.

3725) xpfe/bootstrap/nsNativeAppSupportWin.cpp:958 [3] (buffer) getenv: 
Environment variables are untrustable input if they can be set by an attacker. 
They can have any content and length, and the same variable can be set more than 
once.. Check environment variables carefully before using them.

3726) xpfe/bootstrap/nsNativeAppSupportWin.cpp:1727 [4] (buffer) strcpy: does 
not check for buffer overflows. Consider using strncpy or strlcpy.

Comment 1

[timeless]

[random]=>law

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I think the OS/2 specific file contains potential buffer overflows, for example: 

654               CHAR pszArgString[CCHMAXPATH];
655               strcpy(pszArgString, TURBOD);
656               strcat(pszArgString, " -l -p ");
657               strcat(pszArgString, __argv[0]);

If CCHMAXPATH is the maximum path length, the above procedure could write more
than that into pszArgString.

I am also a little concerned about this snipped below:

942         static char classNameBuffer[128];
945             sprintf( classNameBuffer,
946                          "%s%s",
947                          nsNativeAppSupportOS2::mAppName,
948                          "MessageWindow" );

mAppName points to a static buffer of size 128. Do we safeguard mAppName in any
way so that it can not be more than 128-strlen("MessageWindow")-1=114 characters
long?

There are also several uses of strcpy that don't seem to be foolproof: copying
to fixed size buffers taking arguments from the command line, etc.

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

In nsNativeAppSupportPh.cpp I am wondering how this can even work:

110    char *splash = NULL;
137    splash = getenv ("ADDON_PATH");
139       strcat (splash,"/splash.bmp");

If it works, getenv() must then allocate more memory than the value that it
returns needs. But this seems wasteful (why allocate more than needed), and how
can we be sure how much more it allocated so that we can safely catenate to the
returned string?

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

In nsNativeAppSupportWin.cpp this is the only part that I am not sure about:

461     int fileNameLen = ::GetModuleFileName( NULL, fileName, sizeof fileName );

Does ::GetModuleFileName() null terminate fileName if the real file name's
length is greater or equal to _MAX_PATH? I would guess it does, but someone
would need to check. If it does not null terminate we would end up passing this
value to other method(s) that expect null terminated strings.

Comment 5

[timeless]

that's funny. ADDON_PATH is a *BeOS* setting, and um, it's a : delimeted thing.
I'll patch it.

Comment 6

[timeless]

Attachment: qnx splash screen change (-w)

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 105152 [details] [diff] [review]
qnx splash screen change (-w)

The allocation is the wrong length; add 1 for a null please (and don't forget
to add 1 to filelen when doing the second strncpy)

Comment 8

[Dean Tessman]

I'm pretty sure GetModuleFileName null-terminates a string that's longer than
nSize.  "If the length of the path and filename exceeds this limit, the string
is truncated."

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Ok, Windows warnings are safe.

Reassigning to mkaply since the majority of the warnings are in OS2 code. Once
you are done, please reassign to timeless if the BeOS issues have not been
solved by then.

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Closing all open flawfinder bugs as WORKSFORME because we now have much better tools that do the same (well, better) kind of analysis (Coverity, Klocwork).