Amateurs can't figure out why this code is potentially dangerous:

rewrite it in Rust

I don't have this in my Microsoft OS

I'm still wondering what asshole went and put something like scanf in a language with fixed length strings. Seriously, that guy is a fucking retard.

You have been visited by the Laura of mediocre threads.

This thread is about to die with only 12 replies. OP, hopefully you got what you desired out of it and that it wasn't a total loss.

Attached: Laura.png (130x210, 55K)

#include

int main()
{
char name[16];
printf("please, say your name: ");
scanf("%15s", name);
printf("Hello mr %s!\n", name);

return 0;
}

>why this code is potentially dangerous
It's in C.

This code is potentially dangerous because it uses scanf. Literally compilers now warn you to not use scanf. People who don't know why this is dangerous are not amateurs, they never even tried.

The buffer overflow attack that this code allows is overwriting the return address on the stack and nothing can protect you from it because stack is meant to be written to.

>what is ROP

>Literally compilers now warn you to not use scanf
Well, gcc tells me nothing. Although every competent compiler nowadays has a stack protector which is enabled by default, so at best this can only be used as a DoS attack.

Attached: Untitled.png (652x198, 4K)

Because it's written in C.

Have sex and sage

I've seen password authentication like this.

use std::io;

fn main() -> io::Result {
let mut buffer = String::new();
println!("Please enter your name.");
io::stdin().read_line(&mut buffer)?;
println!("Hello {}!", buffer);
Ok(())
}

congrats, you know what a buffer overflow is OP. We're all so impressed with your pro knowledge.

the noise in this simple snippet of code is fucking monstrous.
who in the right mind thinks
fn main() -> io::Result
is somehow better than
int main()

am I safe with Python?

Attached: 1562136398874.jpg (612x612, 20K)

/thread

buffer overflow?

Potential buffer overflow at the scanf, the amount read in might be longer than 16 chars (including the null). Hope you get an A!

blessed /p/oster

>so at best this can only be used as a DoS attack.
Lol what, even in the example you have it is pretty possible to get past the canary and overwrite the return address and still not trigger a stack smashing error, since many programs use terminator canaries to avoid gathering entropy from the system.

>basic user input is a security hazard in C
the following is also valid if you're autistic.
Who in their right mind thinks that introducing a security hole is somehow better than performing the same task in fewer lines safely, all while handling Unicode characters correctly?
use std::io;

fn main() {
let mut buffer = String:: new();
println!("please enter your name");
io::stdin().read_line(&mut buffer).unwrap();
println!("Hello {}!", buffer);
}

pic related

Attached: 1518728812617.jpg (1200x1535, 1.87M)

anyone who understands types in programming languages?

Having a type which can contain an error message and which is integrated into the language makes more sense to me than "here's an error code with no context, go fuck yourself"

If you're a brainlet, you're never safe, but yeah, Python is safer.

using an integer for an error message is almost as retarded as using a byte for a unicode character

What is wrong with ScanF and whats the modern alternative ?

You're unable to specify the size of the buffer if you only use %s so it doesn't know to not write past the end of it (buffer overflow). There are ways to specify the buffer size with scanf though and even to make scanf allocate a buffer on the heap that's just the right size for you, but I believe the latter is a GNU extension.

In a larger program you still might be able to redirect control flow before the stack canary check. You might not even be able to right past the canary and touch the saved return address and could potentially overwrite function pointers.

>right
meant write

Name could be longer than the variable?

Incredibly dangerous because it implies that the user is male

Attached: 1564722246344.png (1693x1955, 1.15M)

I am almost certain if you were to build OPs code with any up-to-date compiler for a sane operating system using default settings for the stack protector, it wouldn't use a terminator canary, but feel free to show me a counterexample.

Attached: Untitled.png (750x559, 17K)

If you don't have access to a source of randomness, then you can't use random canaries (some embedded chips for example). Also, using a terminator canary can be forced by the OS, since reading from fs is essentially relying on OS specific features. xorl.wordpress.com/2010/10/14/linux-glibc-stack-canary-values/
More saliently, canaries are randomized per program invocation, not per function invocation. As a result, if there were even one more scanf, you would leak your canary.