ishangsf/rspec
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Modiful rules S5281,S2275: Mention the safer std::print alternative in the RSPEC (CPP-5027) (#3820)

Browse Source
This commit is contained in:
Marco Borgeaud 2024-03-27 11:41:54 +01:00 committed by GitHub
parent 1472750a3e
commit 05d0bcc1e3
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 28 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
rules/S2275/cfamily/rule.adoc
View File

@ -1,10 +1,11 @@
== Why is this an issue?
Because ``++printf++`` format strings are interpreted at runtime, rather than validated by the compiler, they can contain errors that lead to unexpected behavior or runtime errors. This rule statically validates the good behavior of ``++printf++`` formats.
Because `printf` format strings are interpreted at runtime rather than validated by the compiler, they can contain errors that lead to unexpected behavior or runtime errors. This rule statically validates the good behavior of `printf` formats.
The related rule S3457 is about errors that produce an unexpected string, while this rule is about errors that will create undefined behavior.
Starting with {cpp}23, `std::print` should be preferred: its arguments are validated at compile-time, making it more secure.
=== Noncompliant code example
[source,cpp]
@ -36,7 +37,15 @@ This rule will only work if the format string is provided as a string literal.
== Resources
* https://www.securecoding.cert.org/confluence/x/wQA1[CERT, FIO47-C.] - Use valid format strings
=== Standards
* CERT - https://www.securecoding.cert.org/confluence/x/wQA1[FIO47-C. Use valid format strings]
=== Related rules
* S3457 - Format strings should be used correctly
* S5281 - Argument of "printf" should be a format string
* S6494 - {cpp} formatting functions should be used instead of C printf-like functions
ifdef::env-github,rspecator-view[]

20
rules/S5281/cfamily/rule.adoc
View File

@ -1,10 +1,11 @@
== Why is this an issue?
It is a security vulnerability to call ``++printf++`` with a unique string argument which is not a string literal. Indeed, if this argument comes from a user input, this user can :
It is a security vulnerability to call `printf` with a unique string argument that is not a string literal. Indeed, if this argument comes from a user input, this user can:
* make the program crash, by executing code equivalent to: ``++printf("%s%s%s%s%s%s%s%s")++``
* view the stack or a memory at any location, by executing code equivalent to: ``++printf("%08x %08x %08x %08x %08x\n")++``
* make the program crash by executing code equivalent to: ``++printf("%s%s%s%s%s%s%s%s")++``
* view the stack or memory at any location by executing code equivalent to: ``++printf("%08x %08x %08x %08x %08x\n")++``
Starting with {cpp}23, `std::print` should be preferred: its arguments are validated at compile-time, making it more secure.
=== Noncompliant code example
@ -28,7 +29,18 @@ void f(char* userInput) {
== Resources
* https://owasp.org/www-community/attacks/Format_string_attack[Owasp: format string attack]
=== Documentation
* {cpp} reference - https://en.cppreference.com/w/cpp/io/c/fprintf[`printf`]
=== Standards
* OWASP - https://owasp.org/www-community/attacks/Format_string_attack[Format string attack]
=== Related rules
* S2275 - Printf-style format strings should not lead to unexpected behavior at runtime
* S6494 - {cpp} formatting functions should be used instead of C printf-like functions
ifdef::env-github,rspecator-view[]