rspec/rules/S5801/cfamily/rule.adoc
Fred Tingaud 16f6c0aecf
Inline adoc when include has no additional value (#1940)
Inline adoc files when they are included exactly once.

Also fix language tags because this inlining gives us better information
on what language the code is written in.
2023-05-25 14:18:12 +02:00

77 lines
3.3 KiB
Plaintext

In C, a string is just a buffer of characters, normally using the ``++null++`` character as a sentinel for the end of the string. This means that the developer has to be aware of low-level details such as buffer sizes or having an extra character to store the final ``++null++`` character. Doing that correctly and consistently is notoriously difficult and any error can lead to a security vulnerability, for instance, giving access to sensitive data or allowing arbitrary code execution.
The function ``++char *strcpy(char * restrict dest, const char * restrict src);++`` copies characters from ``++src++`` to ``++dest++``. The ``++wcscpy++`` does the same for wide characters and should be used with the same guidelines.
Note: the functions ``++strncpy++`` and ``++wcsncpy++`` might look like attractive safe replacements for ``++strcpy++`` and ``++wcscpy++``, but they have their own set of issues (see S5816), and you should probably prefer another more adapted alternative.
== Ask Yourself Whether
* There is a possibility that either the source or the destination pointer is ``++null++``
* There is a possibility that the source string is not correctly ``++null++``-terminated, or that its length (including the final ``++null++`` character) can be larger than the size of the destination buffer.
* There is an overlap between source and destination
There is a risk if you answered yes to any of those questions.
== Recommended Secure Coding Practices
* C11 provides, in its annex K, the ``++strcpy_s++`` and the ``++wcscpy_s++`` that were designed as safer alternatives to ``++strcpy++`` and ``++wcscpy++``. It's not recommended to use them in all circumstances, because they introduce a runtime overhead and require to write more code for error handling, but they perform checks that will limit the consequences of calling the function with bad arguments.
* Even if your compiler does not exactly support annex K, you probably have access to similar functions, for example, ``++strlcpy++`` in FreeBSD
* If you are writing {cpp} code, using ``++std::string++`` to manipulate strings is much simpler and less error-prone
== Sensitive Code Example
----
int f(char *src) {
char dest[256];
strcpy(dest, src); // Sensitive: might overflow
return doSomethingWith(dest);
}
----
== Compliant Solution
[source,cpp]
----
int f(char *src) {
char *dest = malloc(strlen(src) + 1); // For the final 0
strcpy(dest, src); // Compliant: we made sure the buffer is large enough
int r= doSomethingWith(dest);
free(dest);
return r;
}
----
== See
* https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/[OWASP Top 10 2021 Category A6] - Vulnerable and Outdated Components
* https://owasp.org/www-project-top-ten/2017/A9_2017-Using_Components_with_Known_Vulnerabilities[OWASP Top 10 2017 Category A9] - Using Components with Known Vulnerabilities
* https://cwe.mitre.org/data/definitions/120[MITRE, CWE-120] - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
* https://wiki.sei.cmu.edu/confluence/x/HdcxBQ[CERT, STR07-C.] - Use the bounds-checking interfaces for string manipulation
ifdef::env-github,rspecator-view[]
'''
== Implementation Specification
(visible only on this page)
=== Message
Make sure use of "strcpy" is safe here.
'''
== Comments And Links
(visible only on this page)
=== relates to: S5816
endif::env-github,rspecator-view[]