OpenBSD has removed the format specifier that makes this possible, for hopefully obvious reasons.
josefx • 25 days ago
Was the thought process: "Anything involving C string handling is fundamentally security hostile, lets fix it by breaking %n!"
tom_ • 25 days ago
It is the only one that actually writes to memory. It's occasionally convenient, but it's also largely unnecessary: the caller can typically make multiple calls to printf, for example, noting the return value for each one. Or use strlen and fputs. And so on.
The C11 printf_s functions don't support it at all, so it's clearly already on the naughty list even from the standard's perspective.
trashb • 25 days ago
Can you elaborate on the statement "Anything involving C string handling is fundamentally security hostile"?
lou1306 • 25 days ago
As soon as you forget (or your adversary manages to delete) an \0 at the end of any string, you may induce buffer overflows, get the application to leak secrets, and so on. Several standard library functions related to strings are prone to timing attacks, or have weird semantics that may expose you to attack. If you roll your own security-related functions (typical example: a scrubber for strings that hold secrets), you need to make sure these do not get optimised away by the compiler.
There's an awful lot of pitfalls and footguns in there.
+1
trashb • 25 days ago
lou1306 • 25 days ago
> I thought you meant a hello world or similar program only handling strings would be fundamentally insecure but rather you mean that it is hard to write secure code with C strings.
Disclaimer: I am not the author of the comment, and honestly I am more than happy if OpenBSD broke %n in printf because it looks awful from a security standpoint.
> you mean that it is hard to write secure code with C strings.
Indeed I do :) It is possible to write a "secure" hello world program in C; the point is that both the language and the standard library make it exceedingly easy to slip in attack vectors when you deal with strings in any serious capacity.
Was the thought process: "Anything involving C string handling is fundamentally security hostile, lets fix it by breaking %n!"
It is the only one that actually writes to memory. It's occasionally convenient, but it's also largely unnecessary: the caller can typically make multiple calls to printf, for example, noting the return value for each one. Or use strlen and fputs. And so on.
The C11 printf_s functions don't support it at all, so it's clearly already on the naughty list even from the standard's perspective.
Can you elaborate on the statement "Anything involving C string handling is fundamentally security hostile"?
As soon as you forget (or your adversary manages to delete) an \0 at the end of any string, you may induce buffer overflows, get the application to leak secrets, and so on. Several standard library functions related to strings are prone to timing attacks, or have weird semantics that may expose you to attack. If you roll your own security-related functions (typical example: a scrubber for strings that hold secrets), you need to make sure these do not get optimised away by the compiler.
There's an awful lot of pitfalls and footguns in there.
> I thought you meant a hello world or similar program only handling strings would be fundamentally insecure but rather you mean that it is hard to write secure code with C strings.
Disclaimer: I am not the author of the comment, and honestly I am more than happy if OpenBSD broke %n in printf because it looks awful from a security standpoint.
> you mean that it is hard to write secure code with C strings.
Indeed I do :) It is possible to write a "secure" hello world program in C; the point is that both the language and the standard library make it exceedingly easy to slip in attack vectors when you deal with strings in any serious capacity.
[dead]