Closed Bug 173853 Opened 20 years ago Closed 16 years ago

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

Categories

(SeaMonkey :: UI Design, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: morse, Assigned: mkaply)

References

Details

(Whiteboard: [Win OK])

Attachments

(1 file)

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.
Blocks: 148251
[random]=>law
Assignee: sgehani → law
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.
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?
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.
that's funny. ADDON_PATH is a *BeOS* setting, and um, it's a : delimeted thing.
I'll patch it.
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)
Attachment #105152 - Flags: needs-work+
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."
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.
Assignee: law → mkaply
OS: Windows NT → All
Summary: flawfinder warnings in nsNativeAppSupportWin → flawfinder warnings in nsNativeAppSupport[OS2|Ph|Win].cpp
Whiteboard: [Win OK]
Product: Core → Mozilla Application Suite
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).
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.