Got to love platforms that teach security vulnerabilities as good.

If you don’t mind me asking, what’s the security vulnerability?

@Bubbles If you enter more than 50 characters, which gets() will not check, you will overflow the buffer and write into other data.

*headdesk*

@PrivateGER Oh! So that’s a buffer overflow? So the secure solution would be to check the length of the input before submitting or doing anything with the data?

@Bubbles That too. The smarter thing would be doing it like this.

char[40] string;
fgets(string, 40, stdin);

fgets will never read more than specified in the second parameter.

@jurion Yeah, it is C.

well, what's the site?

SoloLearn.
The site is full with that shit.

@PrivateGER if you ever feel like putting them on blast on social media, it's 100% ok.

if they don't know good C, they shouldn't write a shitty tutorial to make money off of it

@jesustricks Their reputation is already shit, can't make that worse.
It's only popular because it requires zero knowledge to start.

@PrivateGER oh chill so that’s what fgets() does. I’ve tried to learn C but I’ve put it off for a bit, but I’m planning to start it up again soon.

@Bubbles unfortunately that's not good enough. As @PrivateGER has said, the best thing to do is use fgets to limit the input.

Before you can check how long the input is, you have to store it. And before you store it, you have to allocate memory. Buffer overflows happen because for every buffer that you allocate n bytes to and call gets or scanf, some jackass like me will come along and put n+4 bytes in it.

The only safe thing to do this low level is to only take in n bytes. If there's more, you can keep allocating space and handling it.

@deadPix3l oh I see, that makes sense. Thanks for the explanation

I'm completely with you that this bad code but doesn't each program have it's own private memory (as long as it is no mmap), not able to escape it?

@nitwhiz this is true in theory. In practice there are a few things you can do, but it's difficult, usually picked up by heuristics, and not usually applicable (writing kernel mode code changes everything)

BUT code like this makes remote code execution pretty easy. (Or at least did. Its far from easy anymore but still very doable)

@nitwhiz The problem is if we're talking about local variables, they usually live on the stack. A buffer overflow on the stack is dangerous because the function return address usually lives on the very same stack.

That's how a buffer overflow opens the road to code injection / execution from an interface where you're only supposed to deliver data, not code.