how can memory safe code STOP HACKERS?
Вставка
- Опубліковано 28 вер 2024
- Go check out Brilliant and get a 30 day free trial! www.brilliant....
Memory safety is something that we all can't just continue to ignore. But first, before we care about memory, safety, what does that even mean? Is C a memory safe language? Is Rust? How can we count on our code to do what we tell it.
In this video we'll discuss what memory safety is, some violations of memory safety, and how other languages make it better.
🏫 COURSES 🏫
www.udemy.com/...
🔥🔥🔥 SOCIALS 🔥🔥🔥
Low Level Merch!: www.linktr.ee/...
Follow me on Twitter: / lowleveltweets
Follow me on Twitch: / lowlevellearning
Join me on Discord!: / discord
Hmm, as an 'old school' programmer, we used to (sometimes do) use such memory unsafety as a feature, not as a bug (e.g. following arbitrary pointers that the engineer knows about to get a desired value, then calculating the offset between the desired location and an array under your control, then addressing that location using an array index that's out of bounds of the original declared intent). We did this for efficiency and speed at a time when memory and CPU resources were massively more constrained than they are.
I'm kind of glad that such acts are dying out, but there's a twinge of nostalgia and a worry that future SW engineers will come across such code and not be able to understand its function and thus, struggle to maintain it.
You can still do this in Rust, but you need to be explicit about it. This gives the flexibility that is sometimes needed, but also clearly indicates to a maintainer where things could have gone wrong.
Umm, could you write a piece of code depicting it please? I want to see how it works.
I think people are struggling to maintain it because it is "tricky" to begin with - your using the very thing people tell you not to use in often a very platform-specific implementation that can be syntactically terrible to read in order to squeeze in a bit of efficiency - I think it's good that this practice fall by the way side for more semantic approaches to this sort of efficiency gain (like identifying this funky memory magic with keywords that explicate it's unsafety).
@@pravargupta6285 This wasn't written in C and I'm not going to write the language as it'd dox me pretty heavily, but I can explain a simpleish example.
I was fixing a Y2K-like bug in a system where the standard OS date-setting executable wouldn't set the date after 2027 (the system call accepted a 7-bit unsigned int, 1900 epoch+127 years) but the OS was otherwise happy with dates beyond this (internally, a 16-bit signed int was used with the absolute year). We didn't have the executable source to correct.
The way the OS worked was that all of the OS structures could be navigated to from a pointer in the absolute memory value 0xA.
So I wrote a program that ran with kernal-level privileges which, when passed an appropriate date-setting instruction, looked in 0xA, took that pointer to the OS structure (that we called the system block) which further had pointers to other parts of the OS, including the date-time block. So I navigate to the D-T block, get a pointer to the memory location, in absolute memory space, with the year.
I have an array declared. I get the absolute pointer for index [0] of this array. I then subtract that pointer from the pointer I have in the D-T block, to get an int that is the difference, in words in absolute memory, between my array and the D-T block.
So I use that as an array index to write the year to the OS, bypassing the intended mechanism.
@@beckaddison5827 People will, but it's still something that is out there in the wild. I don't disagree at all with what you've said, it's sometimes necessary but far from desirable.
But I see it as a skill along the lines of, say, coding in assembly where it's rarely useful or desirable but it was occasionally necessary and having the skills to understand and maintain it is sometimes necessary.
A greenfield project should never be written that way, but a not-insignificant part of SW engineering heritage that we still rely on is built that way.
Go check out Brilliant and get a 30 day premium free trial! www.brilliant.org/LowLevelLearning
It's really important to consider these things. Your vids are much appreciated
Any chance on you creating a course or series on how to write C programs securely ?
the problem is between the chair and the screen monitor
Well, everybody who knows C is aware that C is unsafe, but it's also very efficient and easy to learn. And there are tools like Valgrind which helps you to prevent memory leaks, segfaults, etc.
C/C++ is so entrenched in the IT world, that I highly doubt it will be replaced in the near future by something like Rust.
While it is true that C is very efficient and easy to learn, no amount of tools has prevented codebases like Chromium to erradicate 70% of its bugs, which are related to memory safety. The same is true in Android, especially on the security side of things: in Android 13, the 1.5 million lines of Rust code that they wrote has had *net zero* memory-related CVEs so far, compared to an average of 1 CVE / 1k SLOC in their C++ code. Valgrind, address sanitizers, they can only get you so far with a language that was inherently not designed to be memory-safe in the first place.
Besides, lots of companies are already using Rust instead of C and C++ for their codebase. C++ in particular is already being replaced here and there. They definitely are entrenched languages in the IT world, but it's becoming more and more viable to do the risky bet of taking the time to rewrite some C++ codebase in Rust, rather than continue to maintain a C++ code. And even when such a risk is not viable, people are integrating Rust in C++ codebases so that all new code is made in it (that's what Android is doing).
@@Speykious Here and there C and C++ can be replaced but not in every cases. For example in game development C++ is still much better choice, for embedded systems C and Assembly are the king. Rust is rust, it's a bit different, for safety-critical tasks it might be better choice, but that's not everything...
C and C++ is much more mature language, Rust is still new compared to them and it has much slower compile time and stricter compiler.
@@matyasmarkkovacs8336 Rust definitely has potential in game development, with projects such as Bevy, Fyrox Engine and Macroquad/Miniquad. You're right, C and C++ are "more mature languages", or more precisely they have a way more mature ecosystem that is old and battle-tested, with standards such as Unreal Engine. But that doesn't mean that Rust cannot "replace" C and C++ in these areas: by that I mean, I'm sure that in a few years, Rust is going to be a much more viable choice for game development than today where it is still in its experiment phase.
And of course I assume the same is true for embedded development, but I know way less about this field since I'm not really interested in it (yet?).
About your last small thing: yeah, Rust has slow compile times, but it also has incremental compilation so generally it's only a problem when you build your huge project for the first time and when you do a release.
As for the stricter compiler... That's kind of the whole advantage of Rust in the first place! That's what has prevented Android from having any kind of memory-related CVE in their huge Rust code. That's also part of why I personally love it. xD
Hey, I just want to say I love these videos as I'm learning reverse engineering. I've seen a few similar bug walkthroughs on your channel but it helps to have it revised a few times.
If you want to convince people to switch to Rust you might want to show an example that any competent C programmer wouldn't spot in a second.
Furthermore the examples you showed in this video aren't actually exploitable on a modern system without additional exploits as ASLR would prevent you from performing a ret2libc attack (without at least precomputing the LIBC location and somehow leaking the ASLR offset) and stack canaries are likely to stop your program in its track before you can overwrite the return pointer anyways unless you also somehow manage to leak it.
I think that's my point. Unfortunately, tons of incompetent C programmers contribute to projects that run the world. The future of languages shouldn't allow the programmer to make memory mistakes.
Also despite ASLR, RELRO, PIE binaries, stack canaries, memory corruption exploits are still super common. Maybe C is to blame.
@@LowLevel-TV Rust has had its own memory exploit CVEs happen and most of the exploits that do happen in that field are actually in C++. fact is high performance high complexity applications are always going to remain in the realm of unsafe and anything outside of that probably shouldn't be written in C/C++ in the first place.
@@zaper2904
It makes no sense to stall against security measures in languages like Rust, it goes without saying that there will be CVE's in literally any language that is using insecure code, and that obviously includes Rust, but that doesn't take away from the fact that real-world applications of the language, including in Android itself, resulted in memory bugs happening than more, and that in itself is a positive thing.
I think your comment is proving his point - the fact that all these vulnerabilities might not be exploitable on modern systems speaks to the fact that these mistakes have been made enough times before, by C programmers apparently competent enough to have their software released on modern systems and that software be popular enough to later be exploited. All this additional overhead, ASLR, stack canaries and the like are required to check behind a binary because of the long history of issues caused by C's (and other unsafe programming languages) inherent trust in the programmers ability to program perfectly. What happens if these basic examples were used in a small embedded platform with a stripped back, custom OS that is designed for that specific hardware? How can we be sure it isn't packed in with all the amenities of modern systems to prevent these basic vulnerabilities from being exploited? We can't, and as a result, IoT devices like those I've described have become some of the easiest targets for exploitation. Rust shifts the responsibility of memory safety off of the system and off of the programmer (except for explicitly unsafe code) and places it on the compiler. That way, we can have incompetent Rust programmers and incompetent OS developers be prevented from exposing simple exploits by using a competent compiler.
@@diadetediotedio6918 Yeah there have indeed been less memory vulnerabilities in Android after they've switched to safe languages 80% of which were Java and Kotlin lmao.
As to why not switch? oh idk maybe Rust not having even remotely the same support as either C/C++ only being able to target a limited number of architectures not having a stable ABI and having a tiny developer population (despite what the internet will tell you) .
Rust is a new fad language its tbd if it actually grows up into a usable language like Java or C++ or dies a painful death like Pascal or Ada for now you're better off using industry standard languages and investing in security tools.
At least C doesn't have esoteric syntax that looks like somebody tried to write Python but had a stroke.
Exactly!
That's one of the main reasons why I prefer C/C++.
Their syntax is much readable and easier.
@@matyasmarkkovacs8336 Rust's syntax is like a fusion of Python, JavaScript and Lua with elements that look like C++.
Also introduces concepts that don't exist in other languages. That's very uncomfortable.
I'm sure you only say that out of familiarity with C. When I first learned C in 1982 it's syntax look very esoteric to me. I had been used to BASIC, ALGOL. PL/M and assembler. To my mind Rust looks superficially quite a lot like C, just cleaner and nicer.
@@matyasmarkkovacs8336 Funny, I feel totally the opposite. I'm happy with C but C++ is hideous and often very hard to read.
@@theabyss5647like the borrow checker or zero cost abstractions? Those features of Rust (unique to Rust I think??) are freaking amazing!
This video makes a big leap from leveraging uaf and out of bounds indices to overwriting memory outside of the programs memory space.
Memory safety in the above example would be a greater concern for injecting/reading data from the program.
the auto-generated chapter say that "C is not typesafe" instead of not "memory safe" I'm sure that would confuse some beginners who didn't fully watch this
Should be fixed, thank you for that.
Wait a sec. Hackers don't normally have access to the source code. Only the binary. It doesn't matter if the language is 'safe' if the underlying binary uses pointers to accomplish the task.
Sure but if the source code is from a safe language, then the binary's implementation of the pointers will also be safe.
@@LowLevel-TV But the binary is not safe. It's machine code. It can never be 'safe'. For example, In order to prevent over indexing to an array off a pointer the machine code has to check the index every time. Hackers would have to go out of there wait to include that check.
@@lucidmoses Static analisis can do a ton
Hackers don't modify the binary directly most of the time, except maybe people who crack local software.
Try to imagine a hacker talking to some C program on a remote server, not having the permission to do anything else: they don't even have access to the binary. Then exploits like buffer overflows can be fatal to the software, since hackers just need to feed the program some malicious input and they'll be able to get their way into your system by making it execute a function _you_ wrote.
So yes, it does matter a lot to have memory safety in regards to security. It's not about making the binary itself safe no matter the modifications you might do to it, it's about making your program secure _at runtime_ so that hackers can't exploit it with malicious input. And it turns out that a lot of these security problems are related to memory safety problems.
@@lucidmoses Rust does runtime array bound checks.
love your videos
Thank you :)
But, go is better than rust.
The first time I coded it was with the Warcraft 3 editor. It is moslty pseudocode, however it doesn't have garbage collector, this is specially worry because some variables grow exponentially and could render your game unplayable. The thing is I didn't know anything of this at the time, so when I asked why my dota clone was so slow they showed me a tool to detect memory leaks and it had around 3,000 leaks that I have to fix manually.
You're acting like it's hard to fix these faults in it.
Data Oriented programming and data validation are two things easy to implement in your coding habits.
I program assembly on retro game consoles as a hobby and I'd argue it's even easier since you usually know in advance how much ram you have from the beginning. A few techniques I've come up with are:
* A "dummy" function that immediately returns. This is useful for padding jump tables or loading as an interrupt vector when none is needed, in the event of a spurious interrupt
* Using a bitwise AND to constrain an array index to always be in bounds before performing the lookup.
* Don't allow bad input to begin with, rather than trying to fix it later.
* If you suspect the user may misunderstand what to do, either rephrase it or make what actually happens the same regardless. For example if I ask a user for a file name, rather than just saying "Don't include the file extension" I'll secretly strip it off then append it back. That way, regardless of whether the user enters "MyFile" or "MyFile.txt" the program turns it into "MyFile.txt" before going any further. The user doesn't need to be "correct" about how to do it!
If you don't mind, could you explain how DOP and data validation solve the issue of memory safety and bugs?
i came here to comment that i will never watch clickbait videos. just came to post this, not watching the vid
Hopefully someone will put together a Rust vs Ada challenge toward absolute safety...
Yeah...
At least Ada has a very nice and easy to read syntax, while Rust's right the opposite.
@@matyasmarkkovacs8336 Have you ever tried to write a non-trivial program in Ada? It's *exhausting*! At least when writing Rust I don't have to look into the *****FUCKING LANGUAGE SPEC***** because I chose one of three redundant but slightly different ways to pretend to have inheritance instead of another.
@@АнтонГусев-н5ю I have seen some complex source codes in Ada, and it's still much more readable than Rust in my opinion. Ada uses keywords wherever it can, instead of symbols.
@@matyasmarkkovacs8336 what do you mean symbols? The only Rust specific symbol I can think of is ', but its impact is minimal.
These are good points - until I want to code a 90's style savage monster piece of software for personal, or off-line admin use.
You can't do that kind of coding in rust AT ALL, and it's VERY difficult to do well in C++.
In C though, you can just restrain yourself and make the code safe, by deciding not to make a rabid beast of flexibility and optimization.
You can even straight up say, "I'm not using pointers", and use functions normally instead. Then, you'll have perfectly functioning C code, without the security pain of pointers.
I know that pretty much defeats the point of C, but simple in-house rules like that go MUCH farther than blunting the edge of a tool because people have been cutting themselves on it by rubbing it with their hands.
i just write 87 line of code and got 1000+ direct/indirect memory leaks after X11 and GL binding using C/C++. just try something new for me🙂
I'm not a fan of Rust. I don't get why people try to push it to replace C. Personally, C is an amazing language compared to Rust.
I do see a world where you don't plague my youtube suggestion....
I'd have expected you to talk about sanitizers, but otherwise, good video.
It is not the code of language being unsafe, it is a programmer being unsafe))
Wow, spoken like a true entitled and infallible being...
I tell people who ride bicycles that the most important piece of safety equipment is the thing inside the helmet. Same thing goes here. Your knowledge of a programming language and how it can be unsafe is the most important protection you have against writing unsafe code. No language will protect you from everything. Just as wearing a bicycle helmet isn't going to protect you from a car hitting you at high speed. The dangers are always there. Relying solely on safety equipment to protect you shouldn't be your primary plan. Know what can go wrong. Anticipate what can go wrong. Develop skills and habits that catch or avoid those problems.
Your "thing inside a helmet" is infallible...?
RUST is nice but there might be solutions needed which cannot be accomplished in an efficient way with it, for example if you need to write a garbage collector. Anyway, any serious developer should learn C which helps a lot with other programming languages as well..
make a video on lifetime parameters in rust
I would love to see Javascript engines of today replaced with Rust versions. Makinb exploits in Javascript less likely would help ward off attacks like malvertising.
How safe Javascript is has nothing to do with Javascript. It depends entirely on your browser. Unless you wrote your own there is NOTHING you can do about that.
You're explanation and guidance were very clear, easy to follow - via the incognito mode. However, via the Office app, it is only a free 5-day trial. Am I doing something wrong?
Rust isn't necessarily safe in safe mode because you can artificially extend lifetimes.
ua-cam.com/video/vfMpIsJwpjU/v-deo.html
For a videogame, being memory unsafe can be really neat sometimes...
True that
It's what gives Missingno its iconic look. Although it was obviously unintentional, the game took some section of ROM and ran it through the sprite decompression algorithm. It's like if you could typecast a word document as a JPEG and get a bunch of noise as an image.
Sometimes I write in c when I want to punish myself
same honestly.
If memory unsafety wasn't allowed, memory scrapers literally would not exist. It physically would not be possible to see the memory of another program (or even your own for that matter) in extremely useful ways. It's literally how a debugger functions. By peeking into memory that it technically doesn't have access to, but needs to see anyways. Lol.
Laughs in memcpy
Hahahaha, no, neither C not C++ will be replaced by Rust. For starters you are talking of C and C++ as if they had the same features and we're the same language when they're not. In C++ using pointers is flat out unsafe and discouraged by the standard and any linting tool will warn you as such, but just like in Rust, you can ignore it and shoot yourself in the foot. You can even do that in C#
Stop holding the developers hands.
I was taught C in college because I spent most of my time programming microcontrollers. Of course, I have been out of it for several years now, but one thing I remember being taught was to be extremely careful with what you allow the user to have access to. One of the big ones was to never let the user have direct access to memory. I was taught to take the inputs in first, test them for validity and safety, and then work with them. That anyone would wrote code with direct or dangling memory access just seems, at best, lazy or, at worst, malicious to me.
Malicious in what sense? That they're purposefully leaving a backdoor so that they can come back later under a different alias and release their malware for it?
@@erikkonstas that would be one way. Purposely leaving a means of hacking the program.
These are all beginner level mistakes.
Yes I see and I liked the video! But I don’t see a world where c and c++ will be replaced. They are just too fundamental. Even Ocaml that was originally used to create rust was created in C. You can’t really avoid the usage of C.
Would you consider Go a memory safe language?
It has a garbage collector, I don't see why not
nah we dont like checks they make us go sssslowwww
@@SomeRandomPiggo Garbage collector prevents memory leaks, not memory corruption bugs
Go is a memory safe language, yes.
@@tf9350 Isn't that a fault of the hardware?
There you have it. Rust is designed to take away developer freedom by hand holding and babysitting the developer.
you are just another one youtuber making a cheap Rust ad - wow how Rust is amazing ! unbelievable ! in comparison with 1st degree programming student C's code... nothing new
But of course Rust is a safe language. How a language that has nothing written in can be unsafe after all?
P. S. It's a joke guys. It's not even mine, saw it somewhere, couldn't resist an urge to use it.
hahahah all noobs program in C with 0 knowledge about how machine code works and then complain boohooo i have memory leak boohooo i cant allocate memory
Yawn. Another rust infomercial.
Literally, I thought this guy would be a bit less shilly about Rust... Oh boy I was wrong. 😆
That's why we need Golang
Android + Rust is amazing
2:20 did you just typedef struct??????? SUM GENIUS SAID TYPEdefENG SRUCTS IS BAD!!!! :MAD FACE: :MAD FACE: :SWEARING FACE:
"The author of this code managed to pack 7 bugs into it"
That would sound like me, but I don't program in C/C++.
I really like that you emphasized the last part "Memory Safe != Memory Secure" since I hear many times that unsafe code is insecure code. But the same could be true with safe code if not implemented properly as well. Although, I believe that memory safe languages can help lessen the time to fix memory related bugs or security issues.
Yes. Unsafe blocks are such a great feature. It gives an option for the developer to access memory however they want when needed. It creates something like a "danger zone", or "do not touch unless you are experienced enough to know what is happening here" zone. I think it makes it easier for junior developers to implement features in low level code.
C plus a decent linter and fixing such warnings results in memory safe. You don't really NEED a whole new language to do this. Just use better static analysis.
@@kayakMike1000 the language *is* the static analysis. features like lifetimes and specially dedicated unsafe blocks are pretty much absent in other languages as well.
@@kayakMike1000 Static analysis on C has a very limited insight depth and will always have a severely limited insight depth, you can make it work on toy programs comprehensively but it just explodes out of bound as the space that needs to be analysed gets larger. You'll always have leaky, overly permissive C analysis to some degree. You can't even prove aliasing on a C program. The one way you can fight this is a language that leans on the more restrictive side and puts analysis walls that don't need to be traversed, you only need to analyse both sides of the wall separately rather than across the wall. It was a decades long debate whether such a more restrictive language would be a complete menace to actually use, but now such a language exists, and it's fine, it's nice, it covers the usecases of C. It's worth celebrating.
Memory safe languages? You mean unicorns.
Memory safe languages don't exist. Yes rust has nice statistic analysis and runtime environment but even then you can still Fuck up and in kernel level there is no such thing as a runtime and direct hardware access makes any sense of "memory safety" meaningless.
Correct code is memory safe code, there are only languages that help you write correct code but no correct languages.
Nice video! I believe there's another point to be considered; safety versus freedom. Specially in C, you are absolutely free as programmer, you can freely read and write to memory, reinterpret it, execute memory as code, do whatever. That's a powerful feeling and gives you a sense of control over the hardware. I do think safety is extremely important and the main problem in C, but I think that's why both Rust and C have their places.
Good point!
Also you can get a middle of the road approach by using tooling like static analysis, valgrind and alike! Those catch a bunch of memory bugs.
You can do all that in Rust, as long as you put it in an unsafe block. The point is that when you write code like that, you have to thoroughly review and test it to make sure it won't crash or allow for exploits, so Rust keeps these code sections small, contained and clearly marked. But it doesn't prevent you from doing anything you need to do with the hardware.
Ins't unsafe rust just as free though ? I'm just a beginner with it but what I've like the most about rust so far is that any compromise you make is intentional and obvious. Get controll when you require it and deal with the responsibilities of that only when its required.
@@yondaime500 Yes, the same way it is possible to write safe code in C, it is possible to write unsafe code in Rust. But, for example, in Rust to write to an arbitrary address or to reinterpret an array as another type you need to do all these things and almost trick the compiler, while in C you probably won't even get a warning, the compiler assumes you know what you're doing. C has lots of undefined behavior for the same reason, it allows the compiler to optimize much further. What's different between the languages is their focus, Rust focuses on security, C focuses on control. Both of them are extremely useful and will keep being used.
3:45 That's quite the hot take, and I'd have to agree. They don't call C "portable assembly" for nothing. Whether intended or not, it assumes the programmer understands at least one assembly language and computer architecture in general, without giving you the ability to micromanage it. Hell, even I understand assembly and still find C difficult to use. If I have to interact directly with hardware ports I find assembly much easier to write. None of that *(volatile unsigned int*) mumbo jumbo.
I think that's too much of a fact to be considered a hot take lol
to be fair, C89 and C99 are a lot simpler than some of the more recent versions. Just do be sure your macros are doing what you think they're doing.
Dude when I first discovered volatile in C++ it had taken me 15 hours of debugging to figure out that the compiler had completely optimized away my code 😭
I like unsafe memory because i like jailbreak exploits and i love the c programming language (not only for that).
C does make for some fun programming experiences.
That's why I love assembly, you can do a lot of sleazy stuff that would make computer science teachers faint at the idea! Like memcpy() entire functions. Good luck doing that in C.
@@williamdrum9899 i am sure there ways to do it in c like just use inline assembly (x86 :( )
@@williamdrum9899 I did once write a function into a file, read it into a buffer, set the memory to be executable and ran the function in C
I'd be really cool to see how you would take control of the system using this code if you could also set the point values. Exploiting something like this is something that I hear a lot about, but nobody really ever shows an example of it in action to drive the point home and show how this stuff actually works.
IDK who it was, but I watched a while 40 minute video on a security flaw in a core Linux kernel dependable that existed because strings in C are null-terminated arrays, yet the programmer somehow allowed the user to set that null terminating byte. I forget exactly how it went, but by setting that byte to be something else, the terminal would--with a bit of fiddling--run the next command as sudo. It was very well explained, too bad I can't remember the video name.
That's because its bs and fantasy thinking.
To write both code to execute and the adress of that code precisely at the return adress of the stack using an overwrite at an unknown area of memory is near impossible.
It's pure luck when *if* it happens.
At work I've used mostly Rust but also C, I think my C code is better as a result of being scolded by the rust compiler over and over again.
I think its good to have and use Rust for programs that need memory safety to prevent exploits that could create critical damage, but I still prefer to have absolute controll over execution flow and memory management in programs that don't need to be memory safe. Having bugs and playing around with them is fun and actually a good way to learn how to prevent them and also gives me the ability to hack my calculator.
this only makes sense to me now because I started learning Rust (started out with Python 😪), thanks for this demo with C!
Rust is a great language!
@@LowLevel-TV Sadly the devs are chomos
@@bravefastrabbit770 wtf you mean ?
Same
Rust is great and so is C. The learning curve with Rust can be difficult but rewarding
I actually never had to debug a rust program i wrote using gdb or something similar! At most some println! macros where all i needed to find semantic issues in my program.
Its not c its you at the end.
Could you please talk about memory safety in other languajes like go or python where we don't really have control of it?
Recently i got a null pointer de-reference error in go, and was really hard to debug
Having null pointers isn't really memory safety, that's just a feature of Go
You probably had a null object and tried to use it. That's something that happens on most languages (Java, Javascript, C#, Python, etc).
One thing that could be mentioned on another video is memory leaks, which is still possible on garbage collected languages, albeit it's rare (involves specific instances of circular references as far as I know).
Memory safe languages don't stop hackers because most hackers are not looking for memory holes anymore. Dudes. You need to get a life. ;-)
There are many footguns in programming, but memory safety is easily the foot-BFG9000.
I'll go out on a limb and say most exploit chains are going to take advantage of memory unsoundness in some form, unless you're lucky (or really determined) to find a chain of logic errors to get you where you want to go.
Rather than throwing the baby out with the bath water (switching to another language), always test user input and always validate returns...
I agree with all of this, but I’d be very careful with rust. Rust -purports- to be memory safe, and that’s true from the programmer perspective, but not from the hacker perspective.
There have been CVEs for overflows and memory corruption in Rust. Maybe it won’t let the programmer mess with memory , but an attacker can still come in because of bad language implementation.
We expect more CVEs over time just like what happened to other langs.
Still I do agree with the whole thing that C gives us a lot of power and responsibility and that can be a problem if you don’t manage it well.
Not gonna stop me from coding segfaults tho. Tee hee.
I sense HERESY!
The reason why industry still and always will use C for years on :
1. C99.
2. Static Code analysis.
3. Memory leak/valgrind/helgrind and super variety tools for sanitizing.
If you work in commercial projects you do all at once, static, dynamic analysis, unit tests and component testing. C is super simple in that regard.
Fair!
How is that simple compared to Rust where I only need to run the compiler?
@@valcron-1000 you don't need to rewrite your existing code in Rust
and well, a lot of software is maintained for multiple decades if not even longer
@@valcron-1000 The rust compiler is doing more or less the same, but it's already set up. How to make that just as simple: Just like rust, configure the build system to run all the tools you need. I have a "template" Makefile that I use on most project, just adding the static analysis tooling there gets.
@@valcron-1000 Friend. In actual company there is always paid devops or geek who will make 1 command or 1 button function to do all possible checks.
Its 2023 ... and my company still uses Ada ... don't expect C or C++ to be completely 'replaced'...
To be fair you are compiling without warnings on (I wish conpilers would do opt out instead of opt in for this). And the bugs in this code is not bugs any C coder will do, they are just basic C which you learn when you learn the language, just like any other language.
1. C and C++ will never go away. 2. Addressing the memory safety issue, pun intended, I noticed you weren’t using any compiler options that may help catch them. Nor were you using any sort of code or memory analysis tools, or project programming guidelines. All serious, safety critical C/C++ project use all of the above and also go through a code certification process.
1) You're literally trying to predict the future.
2) Wow, imagine every little change in code triggering a whole certification process, like time and money is inconsumable...
Let's be honest. C++ is memory safe these days. You just need to understand its basics like object life times and use its smart pointers for dynamic allocations. You also need to turn on most of the major warning options. That's basically it.
@@SimonWoodburyForget are you comparing the speed of a GC with smart pointers? Smart pointers are still much more efficient than what a typical GC does. And also in C++ standard library, the only smart pointer that has some cost is the shared_ptr. The unique_ptr and weak_ptr are zero cost which means they're as fast as raw pointers. And there are also atomic implementations of shared ptr like pointers that perform faster than standard library's shared_ptr. So not many problems in that regard.
@@SimonWoodburyForget so doesn't rust call any destructors when trying to end the life of an object?
Rust is pretty neat. I think it's good, overall. C will still exist for shenanigans, but the safety of Rust is really nice.
Like you said, there's a lot of stuff that programmers really shouldn't be doing in a normal program, and Rust will prevent entire categories of bugs, just by enforcing some rules at compile time!
Small nitpick: at 5:00 your code is a bit wrong, your puts takes str directly, which is illegal as dynamically sized types (str itself is _any_ legal utf-8 byte sequence, including zero bytes and 10GB strings) cannot be passed directly to functions, only through a fat pointer like &str. Also a real puts would take a pointer to the first byte of a null-terminated string, e.g. *const c_char or *const i8.
things I did and still do in C:
detours: replacing opcodes behind function pointers with relative jumps to hook functions.
this allows me to interject flow for a moment to fix upstream bugs in a video game server.
direct access: writing and reading from bus bound hardware interfaces.
other stuff too.
What a horrible syntax, rust just look like absolutely mess... I hope industry never use that creepy language and it's syntax.
What parts exactly do you find horrible ? The language makes total sense to me
Still a better option than working on a C codebase that abuses macros like hell. That said, there are always simpler options like Zig and Odin.
Couldn't someone write a C compiler that catches bugs like this?
Wdym by giving developer too much power? Is this video the reflection of modern society? I am as salty as it is from living trough 2021,2022 and now 20223, you didn't need to shill rust to make me saltier.
When the people that I was defending tell me that they are replacing me.
Great video... helpful at understanding
the 69 and 420 example hahahah
personally i use nim as my main programming language since it gives a nice blend between c and rust in terms of how much the developer is in control and it also has a lot of syntactic sugar packed in it
but i can say that when i want to use a more obscure library or something like that, i will turn to rust or even c most of the time to avoid making bindings from scratch (which i still haven't figured out how to do, even in rust)
Both C and Rust give you the same level of freedom, what do you mean?
@@Cookiekeks rust is sometimes a bit too restrictive with its safety measures (at least for me), while c is so permissive that even with pedantic warnings i still sometimes end up with programs that behave strangely
@@luna197-old What is still restrictive when using unsafe?
@Peter I do not know anything about this, what is MISRA and AUTOSAR? Also, why does Rust not have a formal specificatio
There is something i don't understand: in the example when you are trying to acces the point 12344, the program crash right? So i don't understand how an attacker can use this to compromise my computer.
If the program crash, it can not be a problem right?
This is why I hate coding in C, why the heck does it compile if it's not gonna work! Runtime errors suck
*cries in assembly*
because the people that write in C are not supposed to be potatoes with 0 knowledge in computer science if you want "easy" life go with python
@@allocator7520 Python is even worse, the error messages don't give info other than it being a traceback
@@maybeanonymous6846 c:
sir one question why we should learn c and is most exploits are written in c
C++ can perfectly solve these problems, no need for Rust.
Yeah, programming in 'safe' Rust using unsafe Rust and C under the hood.
That's why i love C, it even gives me the chance to make mistakes 🙂
Rust doesn't stop you from making mistakes, it just lets you know immediatly.
I'd rather my mistakes happen at compile time than at 4am when things start breaking in production.
Wouldn't you prefer to get educated on why what you did was wrong, rather than going about your life blissfully unaware that there's something wrong?
And this is why memory safe language are better then C for taks where you don't need any really low level stuff.
Where's the fun if I can't even have my severe security problems?
the vulnerable code source. i wan't to test my exp :) or idk just a referance
I do love some Rust propaganda to start my day :)
3:43 bruh yes there are reasons
Meh, I think I'll be sticking with C. Thanks though!
fsanitize=address
Use Rust btw
Can't you fixed these issues with compiler flags? Also I'm not sure how this applies to C++ since Smart pointers are a thing
You would need a new syntaxes and semantics to fix a lot of c/c++ issues. The compiler does not have enough information leading to false positives or lots of missed positives. That being said turn on all the warnings you can and run with sanitizers. They are helpful just not as helpful as Rusts tooling.
The issue with C++ is that smart pointers are good but limited. They only provide ownership with allocation. If you are not allocating then they don't work to convey ownership. This is an issue for embedded or performance critical areas that don't want or can't deal with allocation.
There are other limiting factors as unique pointer has some overhead vs a raw pointer. Shared pointer is always atomic even when you are not in a threaded scenario.
Some times you just want to pass a pointer around and still convey ownership with no overhead. This is what Rust can give you that C/C++ cannot.
Some side note issue with c++ smart pointers are nullability. When receiving a smart pointer they can be empty thus a null check is needed for every(safe) use. This makes api's a bit more unlear.
A better solution is to use optional with your smart pointer but in c++ this takes up extra room and does not even remove the extra null check.
In rust sizeof(&T)==sizeof(optinal) ==sizeof(box) == sizeof(optinal). This allows for no overhead when passing a pointer that can be missing. It also makes it clear when you have to check the pointer for nullability leading to less redundant checks.
Hopefully that makes sense
@@dynfoxx Ah okay thank you for the nice and organized response. I'm still technically new to programming since I started 2 years ago (1 year to experiment learn basics phrases such as IDE and use multiple languages, and another year to understand concepts more such as OOP, learn Linux, and slowly reaching a level of intermediate although I'm still a beginner in various ways).
I do not fully understand concepts such as threading, multi-threading, cocurrency, and atomic but I'll look more into them with key things you wrote about Rust.
Forgive me but I have a hard time reading Rust syntax so I do not fully understand the code you wrote I just interpreted it as Rust doing the redundant checks for you. With that being said I'll keep what you wrote in-mind and if I ever need to work on things that requires tools that C++ doesn't excel at then I'll think about using Rust for the job.
@@doomknight233 Yeah not a problem if you have questions just ask. It takes most people a while to fully understand concepts so take your time.
Threading is difficult to wrap your head around at first. People have a lot of different ways to explain so let me know if this makes sense.
Think of threads as different people in a podcast or radio show. Each one can do different things but in the end it comes out to one audio stream. When you talk over each other it's unclear what it will sound like. How do you solve this?
One way is to only let one person talk at a time, that Is a mutex. Noone can be talking and everyone can just listen, in that case there is no issue. You could have individual microphones for each person, this would be attomics, thread local or something like that.
Hopefully that makes sense to why there is a problem. Atomic are a bit hard to explain but think of it as a mutex for small data.
Think if box as a unique pointer but otherwise it's basically just the same as c++ for sizeof. & is a pointer to some generic T.
C with Rust memory features added with libraries = Crust.
Crust with jokes as error responds = Crusty.
NERD!! lol, I really want to understand this but it's over my head, need less technical explanation. Will return after learning more! Thanks and I'm sure this is extremely useful to anyone who has basic coding skills
No, it isn't. ;-)
Hi all... I am a mobile app developer. Want to learn embedded system but using rust not C. Can any one share a good source to learn the same. Both free and paid. Thanx!
On an embedded system you have to be able to randomly access hardware registers. That's far easier than you think, but you just have to LEARN that skill. You can not expect library developers to take care of everything for you that requires actual LEARNING. And even if you could, you shouldn't because eventually you will be a better coder than those library developers. Most libraries for embedded systems are written by disinterested semiconductor company employees. They are underperforming and buggy. Not to mention that most embedded hardware is buggy and you have to find workarounds for YOUR application.
I am not a programmer even though i know the fundamentals because i happen to like programming but i am pretty sure that, when any language isn't memory safe it doesn't necessarily mean it's a bad thing, because it's about freedom and accountability, because it gives you the opportunity to f up and learn from it, because if you are programming in a language which allows you to write memory safe code, you will very like never be made aware what makes the code you are writing safe, but that's the trial and error method, of course you can learn to write memory safe code by learning it fundamentally correctly from the begging specifically.
Those mistakes are really dumb and don't depict the problem at all.
I swear that if you had an LSP on some of those errors would be marked as such, they are that obvious.
The real problem comes with threads and the kind of memory safety issue that works correctly in all conceivably usecase but it has that one insane edgecase that you are only going to get by forcing it that then turns into an exploit.
yes the vec_new() funtion is wrong, the Vec struct instance should be allocated dynamycly on that function. but i am still not sure if this kind of mistake is happenned in production code. well there is still a chance thought.
I'm so glad I learned C/C++ as my second language, I pity the kids who would return an address to a stack variable. Oh wait, now I remember I definitely have done that at first year at uni and couldn't worked out why it doesn't work.
Interesting topic!
Thanks for the video!