[shakna]

That's a format string attack [0].

By modifying the start of that string, you can begin reading and writing to various parts of the stack.

Whilst implementations may inline that string into a RO memory region - that's not defined behaviour, so you shouldn't depend on it.

[0] https://owasp.org/www-community/attacks/Format_string_attack

[ddalex]

> By modifying the start of that string

In order to modify that string, even in RW pages, the attacker already has to have access, at which point the point is moot. It's like saying "if you can change memory, then you can change memory"....

[DougBTX]

Agreed, if the attacker can modify string constants is,

    printf("Hello, World!\n");

really any safer than this?

    printf("%s\n", "Hello, World!");

[ebeip90]

No, they’re equivalent in terms of security.

The article’s author (posting here on HN) is grossly mistaken.

[hleach]

They are nearly equivalent in terms of functional security.

Function isn't everything though. One example shows an awareness of the security issue and good habit being used despite the low impact. I'd argue that there is a security benefit to using one over the other.

Additionally, it's not as simple as saying "if you can change memory, then you can change memory". Memory exploits are quite often chains of small issues these days and not the simple buffer overflow of old.

For example, being able to overwrite one byte somewhere could lead to the ability to change only part of a variable address. That could be used to redirect a write to the constant string in memory.

Sure it's contrived, but scenarios like this do happen.

[a1369209993]

> One example shows [...]

Yes,

  printf("Hello, World!\n");

shows an awareness of the security issue and good habit being used.

  printf("%s\n", "Hello, World!");

shows that you think "%s\n\0Hello, World!" (or however the compiler decides to lay out those strings) can't be overwritten with "%p%nHello, World!" (or something to that effect), but "Hello, World!\n" somehow can.

[hleach]

You know that reinforcing habit is not about this trivial example. You are arguing in bad faith.

We've spent the last 20 years cleaning up after the shoddy work of this exact attitude.

[dezgeg]

By that same logic, puts("Hello, world!"); is also vulnerable to DoS attack and information leak since someone could have removed the NUL terminator at the end of the string and have puts() read uninitialized/unmapped memory. Which is absurd logic.

[shakna]

Format string attacks have occurred in the wild. [0]

> Originally thought harmless, format string exploits can be used to crash a program or to execute harmful code.

They are not the same as puts. Puts can allow you to potentially read memory.

A format string attack can allow you to write to memory.

[0] https://en.wikipedia.org/wiki/Uncontrolled_format_string

[cozzyd]

Yes if the attacker has control of the string (like if you do printf(getenv("FOO")) or something equally stupid).

[scatters]

So an attacker able to write to memory would be able to elevate into the ability to... write to memory. That doesn't sound particularly worrisome.

[nocturnial]

In a lot of cases the attacker can only write to a limited range of memory addresses. If that string happens to fall in that range, they can use it to write to other addresses and/or find out where in memory certain things are stored.

So their ability to write to a limited range of addresses can be extended to a larger range.

[a1369209993]

If the attacker can write to string memory, they can overwrite "%s\n\0Hello World" just as easily as "Hello World\n".

[ebeip90]

And what, pray tell, stops me from modifying the memory at your “%s” string’s location in memory?

Nothing.

Neither is more secure, all modern compilers put both “%s” and “Hello, world!” in rodata sections.

Your understanding of practical format string attacks is misguided.

[slavik81]

It's also not defined whether the executable code is in RO memory or RW memory. By your argument, we should also be concerned that the attacker could modify the code directly.