Flawfinder

Check buffer boundaries for vsprintf

Can an attacker redirect a file (via symlinks), force the opening of special file type (e.g., device files), move things around to create a race condition, control its ancestors, or change its contents?

chroot can be very helpful, but is hard to use correctly

CreateProcess, CreateProcessAsUser, CreateProcessWithLogon cause a new process to execute and are difficult to use safely

DES only supports a 56-bit keysize, which is too small given today's computers

_getts, _stprintf, _stprintf, _vstprintf, gets, sprintf, swprintf, vsprintf, and vswprintf do not check for buffer overflows

Does not check for buffer overflows when concatenating to destination (StrCat*, _ftcscat, _mbccat, _mbscat, _tccat, _tcscat, lstrcat, lstrcatA, lstrcatW, lstrcatnA, lstrcatnW, lstrncat, strCatBuff, strcat, wcscat – [MS-banned]) or copying to destination (CopyMemory, bcopy, memcpy) (StrCpy*, _ftcscpy, _mbccpy, _mbscpy, _mbsncpy, _tccpy, _tcscpy, lstrcpy, lstrcpyA, lstrcpyW, lstrcpynA, lstrcpynW, strcpy, strcpyA, strcpyW, strcpynA, wcscpy – [MS-banned])

_mbslen, _tcslen, strlen, and wcslen do not handle strings that are not \0-terminated; if given one it may perform an over-read (it could cause a crash if unprotected)

_mbsnbcat, _tcsncat, lstrcatn, strncat, and wcsncat are easily used incorrectly (e.g., incorrectly computing the correct maximum size to add) [MS-banned]; _mbsnbcpy, _tcsncpy, lstrcpyn, strncpy, and wcsncpy are easily used incorrectly; doesn't always \0-terminate or check for invalid pointers [MS-banned]

Ensure that the full path to the library is specified, or current directory may be used

Ensure that umask is given most restrictive possible setting (e.g., 066 or 077)

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

Exactly what cuserid() does is poorly defined (e.g., some systems use the effective uid, like Linux, while others like System V use the real uid). Thus, you can't trust what it does. It's certainly not portable (The cuserid function was included in the 1988 version of POSIX, but removed from the 1990 version). Also, if passed a non-null parameter, there's a risk of a buffer overflow if the passed-in buffer is not at least L_cuserid characters long

Exceptions can be thrown in low-memory situations

The functions fread, readv, recv, recvfrom, and recvmsg accept input from outside program

The functions equal, is_permutation, and mismatch do not check the second iterator for over-read conditions

Function tmpfile() has a security flaw on some systems (e.g., older System V systems)

If a call to ImpersonateDdeClientWindow, ImpersonateLoggedOnUser, ImpersonateNamedPipeClient, or ImpersonateSecurityContext fails, the program could fail to drop heightened privileges

If format strings of _ftprintf, _vftprintf, _vtprintf, fprintf, fvwprintf, fwprintf, printf, vfprintf, vfwprintf, vprintf, vwprintf, wprintf, and sprintf variations can be influenced by an attacker, they can be exploited, and note that sprintf variations do not always \0-terminate

If syslog's format strings can be influenced by an attacker, they can be exploited

If this call to CoImpersonateClient, RpcImpersonateClient, or SetThreadToken fails, the program could fail to drop heightened privileges

It's often easy to fool getlogin. Sometimes it does not work at all, because some program messed up the utmp file. Often, it gives only the first 8 characters of the login name. The user currently logged in on the controlling tty of our program need not be the user who started it. Avoid getlogin() for security-related purposes

Never create NULL ACLs; an attacker can set it to Everyone (Deny All Access), which would even forbid administrator access

On some old systems, vfork() permits race conditions, and it's very difficult to use correctly

On some systems (though not Linux-based systems) an attempt to free() results from memalign() may fail. This may, on a few systems, be exploitable. Also note that memalign() may not check that the boundary parameter is correct

Potential for temporary file vulnerability in some circumstances. Some older Unix-like systems create temp files with permission to write by all by default, so be sure to set the umask to override this. Also, some older Unix systems might fail to use O_EXCL when opening the file, so make sure that O_EXCL is used by the library

Requires maximum length in CHARACTERS, not bytes

Some older implementations do not protect against internal buffer overflows

Statically-sized arrays can be improperly restricted, leading to potential overflows or other issues (TCHAR, char, wchar_t)

Subject to buffer overflow if buffer is not as big as claimed

Temporary file race condition (mktemp, tempnam, tmpnam)

Temporary file race condition in certain cases (e.g., if run as SYSTEM in many versions of Windows)

The crypt functions crypt and crypt_r use a poor one-way hashing algorithm; since they only accept passwords of 8 characters or fewer and only a two-byte salt, they are excessively vulnerable to dictionary attacks given today's faster computing equipment

The scanf() family's %s operation, without a limit specification, permits buffer overflows (_ftscanf, _tscanf, fscanf, fwscanf, scanf, sscanf, vfscanf, vfwscanf, vscanf, vsscanf, vswscanf, vwscanf, wscanf)

These functions are considered obsolete on most systems, and very non-portable (Linux-based systems handle them radically different, basically if gsignal/ssignal were the same as raise/signal respectively, while System V considers them a separate set and obsolete)

These keysizes are too small given today's computers

This accepts filename arguments; if an attacker can move those files or change the link content, a race condition results. Also, it does not terminate with ASCII NUL.

chown, chgrp, and chmod accept filename arguments; if an attacker can move those files, a race condition results.

This C routine is considered obsolete (as opposed to the shell command by the same name, which is NOT obsolete)

This C routine is considered obsolete (as opposed to the shell command by the same name). The interaction of this function with SIGALRM and other timer functions such as sleep(), alarm(), setitimer(), and nanosleep() is unspecified

ShellExecute, WinExec, execl, execle, execlp, execv, execvp, popen, and system cause a new program to execute and is difficult to use safely

This does not protect against buffer overflows by itself, so use with caution

This doesn't set the inheritance bits in the access control entry (ACE) header

The functions streadd, strecpy, and strtrns do not protect against buffer overflows

This function does not protect against buffer overflows, and some implementations can overflow internally

This function is dangerous; it may overflow the provided buffer. It extracts data from a 'protected' area, but most systems have many commands to let users modify the protected area, and it's not always clear what their limits are. Best to avoid using this function altogether

This function is not sufficiently random for security-related functions such as key and nonce creation (drand48, erand48, g_rand_boolean, g_rand_double, g_rand_double_range, g_rand_int, g_rand_int_range, g_random_boolean, g_random_double, g_random_double_range,g_random_int, g_random_int_range, Jrand48, lcong48, lrand48, mrand48, nrand48, random, seed48, setstate, srand, srandom, strfry)

This function is obsolete and not portable. It was in SUSv2 but removed by POSIX.2. What it does exactly varies considerably between systems, particularly in where its prompt is displayed and where it gets its data (e.g., /dev/tty, stdin, stderr, etc.). In addition, some implementations overflow buffers.

The functions g_get_tmp_dir and g_get_home_dir are synonymous with getenv(HOME) it returns untrustable input if the environment can beset by an attacker. It can have any content and length, and the same variable can be set more than once

This usually indicates a security flaw. If an attacker can change anything along the path between the call to access() and the files actual use (e.g. by moving files) the attacker can exploit the race condition

Unless checked the resulting number of _wtoi _wtoi64 atoi or atol can exceed the expected range