
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.
77 lines
3.3 KiB
Plaintext
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[]
|