What's the deadly bug here, Jow Forums?

OP's just not god but an ordinary faggot.

You have to be a god of faggots to use C.

Not doing your homework :)

b-but it's supposed to be bad, user
i think you're missing the point

fix your own shit

I am not OP, I just don't see anything particularly bad about the code, except for maybe mixing different I/O functions needlessly or calling fflush needlessly. Is it muh globals?

Add a note. Delete a note. Print all notes. Be amazed.

the fflush is actually needed, since the stdout buffer is not guaranteed to flush without a newline or an explicit flush

exploit it fgt

Ah I see it now, he isn't changing the NumOfNotes after deletion at all
Then you should probably reformat your output, function calls are expensive

>Ah I see it now, he isn't changing the NumOfNotes after deletion at all
It's even worse, even if he did decrease it it would still crash.

numOfNotes wouldn't really change anything, you'd still have the bug

function calls are not that expensive, it's literally a non issue most of the times

It literally doesn't crash mose of the time
unless you double free, I guess

Well what he would have to do is decrease the NumOfNotes while moving all later notes to the left I suppose(to not have unallocated holes), or just use a linked list.
On the function calls part, while they are not that expensive, it's still better to not have unnecessary calls for overall performance.

> if (noteNum < numOfNotes){
printf("Deleting %d\n", noteNum);
free(notes[noteNum]);
}

You only free the memory associated with the note, you don't actually delete the note from the array.

Additionally, since you're allocating the memory separately instead of just having a by-value array, there's no telling where the note actually was in memory before you freed it.

It may be possible for an attacker to claim the freed memory and populate the path field with whatever they want, thus allowing them to use your program to view or overwrite any file their user account has the privilege to access, as long as either its absolute path or its path relative to the working directory is less than 50 characters long. Additionally, they could access files with longer paths by allocating more memory than was freed.

I don't think this is actually realistic, since on any operating system I know of, the system will pre-allocate all the memory your program can access, and the actual runtime allocator just operates over that memory space, not the full memory space of the computer; as such, running programs can't access each other's data, even in situations like this. I guess the attacker could prepopulate the memory from a different program, close that program to free its entire memory space, and then run your program and hope the memory they populated isn't reinitialized.

>it's still better to not have unnecessary calls
define unnecessary? it's literally a non issue, especially in C
function calls are literally just a few instructions
not that the fflush is unnecessary either

You got pretty much all of it right, except the last part.

i'm not sure why you think it's not enough of a vulnerability having an arbitrary read access? sure, the process lives in it's own virtual space in isolation, but that wasn't really the point

>I guess the attacker could prepopulate the memory from a different program, close that program to free its entire memory space, and then run your program and hope the memory they populated isn't reinitialized.

The virtual memory isn't shared by other processes at all, I don't think that could ever possibly work

>The virtual memory isn't shared by other processes at all
Not by other running processes, sure, but do you mean to tell me it's not even shared by processes that are no longer running? Because if that's the case, that sounds like a pretty egregious OS-level memory leak????

>typedef struct note{
> char name[50];
> char path[50];
>} note;
>note* notes[100];
>char numOfNotes = 0;
Why do I cringe every time I see a piece of C code? They are unsophisticated, arbitrarily restricted and very poorly written.

I think I'm missing your point, user.

Yes, I'm saying the /virtual/ memory is not shared by processes whatsoever, except when shared memory is explicitly used
The stack is not shared and the heap is not shared
I'm not sure about the static and global variables in, but I'm guessing they aren't either

The /virtual/ memory on the heap is presented as a zeroed out region, containing no data except some malloc and free metadata

and I'm not sure how not sharing the memory between processes constitutes as a memory leak

>The /virtual/ memory on the heap is presented as a zeroed out region,
I see. I get you. This answers my question. If it's zeroed out first, nothing can be done.

It's not that sharing memory between processes constitutes a memory leak, I actually meant the opposite, I was just saying that if a process running now can't share memory with a process that was running before but now isn't, then all the user space memory would fill up in no time because old memory can't be reassigned to new processes.

But if a process running now CAN share memory with a process that was running before but now isn't, then, my thinking, which I now know is not quite right, was that you could use another program, write your string in it, close it, and then start OP's program and hope its virtual memory corresponds to the physical userspace memory that the OS just freed, and then the string you want would still be in that memory. But if the memory is zeroed first, the string would be gone anyway.

They're all avoiding the question because they're all LARPers who don't actually program.

PS: ur code is bad.

This

It isn't elitist to use bullshit tools if you don't have to. I'm good enough at what I do to get a job that doesn't revolve around fixing bugs that don't have to exist

It's fast because we have compilers for it that have existed and been optimized for decades.

That's it mane.

Attached: 1567019573816.jpg (753x999, 118K)

>pic
lol dude literally just use valgrind

anyway it's more than that, it's also because C's semantics are closer to how the computer and operating system actually work than the semantics of most other languages used today

C is just really fast and memory efficient and thats why it's still so widely used
it's also quite low level and let's you have more control over your program (for better or for worse)
not to mention many other languages still use libc as a base

fpbp

Can someone please explain or point me in the right direction concerning

note* notes[100]

Probably fgets() to avoid overflows

An array of 100 pointers, each to a note struct.

Why are you inconsistent on where you place the *?

...

do your own homework ffs

also >actually using switch ever

lolling @ ur lyfe

Attached: 1547223446835.jpg (221x228, 11K)

Switch is the most powerful statement in the C language you retard

>C's semantics are closer to how the computer and operating system actually work
>this meme again

Attached: oh i hate this.png (208x208, 20K)

C's switch statement has nothing on Rust's match expression.

It's true though, C's semantics fundamentally don't require as much abstraction to implement.

No, it's still elitist if your attitude about it is that you think the bullshit tools you use are marks of status.

I think what you mean is, it isn't *elite*. You can be elitist without your elitism being founded in reality.

What version of GLibC? I am guessing heap exploit by the looks of it. Compile flags? ASLR?

You can forge a note by deleting and having the first note have the forged contents, then viewing that note. You could read arbitrary files. Are we going for shell?

>create a struct which is a variable that holds other variables
>assign a variable to that variable
>create an array of addresses that contain the possible future addresses that future instances of each struct variable may need

This isn't practical for most programs, specially for a program that simply stores string (oh sorry ARRAYS OF CHARS). We already figured that out years ago and abstracted that micromanagement bullshit out of the way, but the spergs on Jow Forums keep writing stupidly simple programs on C and shilling C here because they want to feel purists and feel like hax0rs I don't fucking know.

If you're not writing firmware or drivers or some other specific thing you have no business using C. I doubt anyone who browses Jow Forums writes firmware.

C is good for VMs as well

>scanf

Attached: 1543428676247.png (501x445, 192K)

>it's also because C's semantics are closer to how the computer and operating system actually work

no it's just a language that was made when hardware limitations where incredibly strict so you had to micromanage every single byte you had
it was good for the time and now it's just vaporware or it's used for programs that have to operate under severe memory limitations (which is getting rarer and rarer)

if it's so cool to talk to the machines who not write assembler? that is as elite hacker machine interface as you can get

C is high-level enough to use comfortably, assembly isn't.

this
OP is a massive faggot as per usual

It's a programming challenge. It's common for capture the flag events and for wargaming and challenge websites. The fact that anyone would respond to OP posting a challenge with anger or negativity only shows how ignorant you are.

Attached: 1567995511593.png (1196x662, 512K)

I'm sure you would rather be posting in some "totally organic" thread about some consumer product that has a bait topic to incite conversation about a company. Sad.

well this is Jow Forums
rarely anything constructive happens here

Sure, buddy. Keep saying that in your broken English until it is true.

what's broken about it friend?

Can’t you create a file within that directory that is super long and contains a NOP sled?

why would you want to fix it? the more bugs, the better

>Your entire code is ze bug
Ding! Ding! Ding!

Nice code, thanks, I will be stealing it for my projects.

>What's the deadly bug here, Jow Forums?
Where do I start..
Buffer overflow
Not checking file
scamf
no input checking

What an absolute cringe

Attached: have sex.gif (1908x1042, 3.61M)

latest version of glibc in the repos, but doesnt really matter
no additional compile flags and ASLR turned on

really close, but not quite
no shell though

>buffer overflow
where?

>notes[numOfNotes] = (note*) malloc(sizeof(note));
oh nonononono Jow Forums

Attached: 1553791787085.png (360x346, 58K)

>strcpy(notes[numOfNotes]->path, path);
well that was pretty obvious

it's typedefing the struct away

are you trying to prove you can't actually read code?

no, i didn't remember the argument order of strcpy because nobody uses c string functions

>fgets(content, 100, fp)

Attached: Screenshot from 2019-09-11 17-43-28.png (1742x990, 180K)

Oh god...
Your code couldn't be more retarded:
1-: A lot of magic numbers that may overflow, as they don't grow as necessary (so why even using heap, instead of stack)
2-: Assuming safe input
3-: Not checking malloc
4-: Storing paths, instead of fd's
5-: Not removing the files when they are uneeded
6-: Resource leak
This has zero safety consideration, any "main" exploit is just another one in an ocean of possible exploits

More fun is using heap when you have zero intention of accepting any buffer size.

>integer overflow
not exploitable here
>assuming safe input
not exploitable here
>not checking malloc
not exploitable here
are you even trying right now?

and again, /bad/ code is the point of an intentionally exploitable program
i still haven't seen a working exploit, user

using C is the issue

> Memory corruption isn't exploitable
Imagine being this much of a brainlet

> /bad/ code is the point of an intentionally exploitable program
t. brainlet that couldn't write non-retarded code with the exploit

This is an entry level challenge from hackthebox and the absolute faggot that is OP wants you to solve it for him. The code is supposed to be bad.

holy shit
imagine coping this much because you can't exploit babbys first vuln

>>not checking malloc
imagine actually thinking this is memory corruption
oh god

> imagine coping this much because you can't exploit babbys first vuln
t. retard that thinks that this code has only one way of being exploited

> imagine actually thinking this is memory corruption
t. brainless retard that don't know what memory corruption means nor what points i cited cause them

>The code is supposed to be bad.
Having multiple exploits discard any sense in searching for a specific one, undefined behaviour and memory corruption usually causes a lot of real problems when happens in real world

>scanf
That's literally the first thing they tell you not to use. You're not l33t hacker you absolute fag.

i'm sorry, user, but t. statements are not arguments in the slightest
you still haven't posted not even one of the supposed "many" exploits here

there may be multiple possible vulnerabilities, but literally only one vuln that you could practically exploit
an exploit is not the same thing as a possible vuln
undefined behaviour, possible slight memory corruption and other things are just possible vulns, if you don't actually have a practical way of exploiting them

>using scanf for inputting numbers is bad
ok user, if that's what they thought you in school go with it

so many options to choose from... i give up, cant decide on one.

>usually
show how exactly, not just repeat blanket statements your pajeet tier tutorials told you
every retard can point out "oh this piece of code isn't 100% safe", it's called valgrind

Of course you, as a brainlet with severe dementia, isn't able to understand what being "vulnerable" means, and as such couldn't specify what type of vulnerability you expect. (in here you have data exposition, memory corruption (that have undefined results), races-condition)

t. brainless retarded, that thinks that is not a pajeet
> heartbleed was only a buffer overflow (memory corruption)
> lots of permission escalation are only races