Will Rust Solve Software Security?

[Music] thank you [Music] foreign [Applause] [Music] University in Pittsburgh Pennsylvania we welcome you to today's SEI webcast will Rust solve software security my name is Shane McGraw Outreach team lead here at the SEI and I'd like to thank you for attending we want to make our webcast today as interactive as possible so we will address as many questions as we can you can submit those questions in the YouTube chat area now like I mentioned we will get to as many as we can our featured speakers today are David sabota and Joe Seibel David is a co-author of the books the search Oracle secure coding standard for Java and Java coding guidelines and a major contributor to the SEI coding standard and SEI cert C plus plus coding standard is taught courses in C C plus plus in Java secure coding all over the world to various military government and banking groups Joe Seibel is an associate software engineer in our cyber security foundations directorate of the serp division he specializes in coding and Linux systems administration his work with DOD customers to ensure that secure coding rules are being followed to implement devsecott practices he also maintains the SEI cert ing standards Wiki David and Joe thanks for joining me today and now I'd like to turn it over to Jojo all yours thanks my name is Joe Seibel as you mentioned this is Dave saboda today we're going to be talking to you about rest solving software security so I'll start giving the introduction going over this rust security model then I'll hand it off today to discussed limitations the current vulnerability ecosystem instability of a short maturity and then I'll take it back for a conclusion so a little bit of introduction and background on Rust So In traditional programming languages like C it's easy to write code that has security vulnerabilities in it especially memory safety vulnerabilities like buffer overflows or use after freeze some languages have strong type systems and other safety guarantees think like Java but they're heavyweight big run time really slow garbage collection causes non-deterministic performance a lot of other downsides so Mozilla realized this was a problem it was steering a lot of people towards the unsafe languages so they worked on creating a language that wouldn't have these problems in either sense The Best of Both Worlds in a sense so rest is what they came up with it's meant to be a systems language I think competing with C plus primarily Pals directly to machine code like CNC plus plus no garbage collection and then they did learn a lot of lessons from Modern languages like functional programming like the strong type system cargo is the one build system for rust everything in Rust is encouraged to use it you don't get the mess and see where some project use auto tools some you see make some use whatever other thing they feel like using and then just a little bit of context on all the guarantees rest is going to provide rust code can be put into two categories safe which is most rust code an unsafe which is always clearly annotated as such in the source so almost everything you'll write and rust is going to be safe for us what has to be unsafe are things like the implementation of its own standard library or if it writes code that interfaces with C code since you can't know what c is going to do so when you you're writing safe for us the guarantees of rust are something you rely on you don't have to worry about causing undefined Behavior because a language protects you from it when you're writing unsafe rust then all arrest guarantees become obligations for you instead in unsafe rust it's your job to make sure you don't let safe rest break any of those rules and then unsafe for us that does that correctly is called sound and if it does it wrong it's unsound and soundness bugs are that category of bugs so what you're saying basically is um um unsafe for us kind of gives you the same power along with the same danger that you get with c and then save for us gets you you know less power but also also less danger is that is that a good way of putting it right so the idea is you spend as little time in unsafe rest land as possible and that gives you the maximum safety guarantees do what you can just to make rust just a little bit more powerful without making it more dangerous and unsafe for us and do everything else and say for us so the big feature that Russ brought to the table in the world of programming languages is its borrow checker so in Rust every object always has one owner when you create an object you own it and then you can either give ownership away when you pass it by pass it moving it to another function or you can let other code borrow it so every borrower is either immutable which means read only or mutable which means read write so there can be as many immutable borrows as you as you want at a time but there can only be one mutable borrow and if there's a mutable bar there can't be any immutable bars at the same time and then the other key rule is all borrows have to be returned before the object can go away or have its ownership transferred away and those rules together are basically the core of every safety guarantee rest offers as we'll see in the next couple of slides so the security model arrests now so as I mentioned before C and C plus plus memory unsafe really easy to cause buffer overflows use after free a lot of other vulnerabilities too Java does all the checks at runtime so if you go out of bounds in an array for example in Java you're going to get an exception at runtime so no security vulnerability but your program still crashed in production one of the advantages of rust is it catches most of these kind of mistakes at compile time before they can become bugs so here's an example of a c plus program that has undefined behavior in it so it creates a vector starts iterating over it then appends an element to the end of the vector and then continues using the iterator so when you append an element to a vector it might need to reallocate and if it does then all iterators are invalidated which makes that final line undefined behavior from referencing freed memory and neither GCC nor clang will give you any warnings when you compile this program undefined Behavior will just happen at runtime it might just give you the wrong answer it might seg fault or it might even work fine when you test and not break gets to production or until you change some of our unrelated bit of code somewhere else that's what makes undefined Behavior super dangerous it's unpredictable and hard to find unpredictable undefined behavior is sort of the standard committee's way of of washing its hands and saying you know whatever you do now you're on your own we're not going to make any more guarantees what the program can do so here's an equivalent program written in a rust so you can see the similarities also creating a vector starting to iterate over it pushing an element onto the end of the vector and then continuing to use the old iterator so this has the same problem as the C plus program that iterator is invalid there but this is safe for us so there's no undefined Behavior so rust catches this at compile time with this error colorful so what it's saying here is when you created the iterator you immutably borrowed the vector and then when you push to push an element into the vector that mutably borrows it the immutable borrow is still there since you use the iterator afterwards so this would have an immutable and immutable bar at the same time which you said wasn't allowed so Russ tries to explain that in detail why that's not okay and why it could be a problem so the error message it's giving you is kind of based upon its own borrow Checkers model to understand this error you have to understand the borrow checker right so here's another example this time this is a c program with undefined Behavior so it takes a string and puts a copy somewhere in the Heap then immediately freeze what it made but goes on to use it anyway so use after free again undefined Behavior common source security vulnerabilities so in this case this program will probably happen to work most of the time until you change something else it could also print garbage it could also set fault and my kind of rule of thumb for thinking of undefined behavior is it works until it needs to yes and again no compilers will catch this with their standard speed of warnings same bug and rust creates a copy of the string on the Heap immediately deallocates it then tries to print it again that's used after free and again rust Catches Us at compile time so drop is how you deallocate objects in a rust when you pass some something to drop you give ownership away to drop and if you remember the other rule of the borrow Checker is all outstanding borrows have to be gone before you give away ownership of an object so here it's saying print line was going to borrow X even though you don't own any more that's not okay and again there's a lot of details in this error message explaining that exactly why and how to get more information if you're confused and again to understand this you have to understand the bar Checkers way of you know understanding things I mean it occurred to me there would be nice but just somebody said use after free error but it gives you what it's giving you is basically in terms of the borrow Checkers mentality right and part of the reason for that is maybe a thing you move in ownership to did something other than free it and wants to keep messages generic and that is one thing that the rest compiler authors realize is this whole thing with ownership and lifetimes and borrowing is new to most programmers so they really went out of their way to make their error messages as detailed as possible and tell you exactly how to get more information if you're still confused yes that is helpful so a couple of other mistakes that rest helps you avoid is null the existence of null is the billion dollar mistake in programming the idea is there's probably been at least a billion dollars worth of problems and lost productivity caused by null so in languages like C any pointer can be in all in Java any reference can be null and the problems that causes are some variables you never want to be null Nothing Stops someone from making one that anyway and some variables are but nothing stop you from using it without a check so what Russ does is they say by default no types can have any equivalent of null if you want something to be optional you have to wrap that in option an option is a separate a special type right options kind of the only type that allows no so it's not even that it's special it's just a generic sum type which is a concept that came from functional programming so the idea is every variable needs a value of its type option is either a unit type just called none but nothing in it or it's sum I sum this time with your value in it so the compiler on forces when it's not option there must be a value there and when it is option your code has to handle the case that being some or none so you can never make a mistake like you can with null that would result in an Aldi reference and runs to invent this as you said it comes from functional programming and it exists in several other modern languages like uh go and Swift but uh yeah it hasn't made its way into Java and C yet well this is actually one thing go is still lacking but yes Swift does include it okay you're right and yeah this yeah this is definitely an old concept Pasco I think from 1999 has that concept they call it maybe but it's the same thing as option so concurrency is the other big kind of mistake that rest protects you against so just about every programming language has the concept of data races we have two different threads both accessing the same memory at the same time so and see that can cause all kind of weird things like you wrote variables in one order then the other thread sees the Rights happen in another another order or you write a variable wider than a word another threat might see half of the right and half of the old value all kinds of problems like that all undefined Behavior so in Russ the borrow Checker prevents you from this because if one thread has the mutable reference to that variable and can change it you know that no other threads can have an immutable reference to it because it's only one with a mutable borrow right and then when you do need to access things from multiple threads that's where there's wrapper types like mutexes and sure other languages like C have mutexes two but you can forget to use them and see and your code will still compile and it will just have a race condition bug and do the wrong thing whereas in Rust it can use like token types built around the bar or Checker to make sure that you can't access the variable if you forgot take the lock or the mutex so that wraps up my section so Shane do you have any questions for us before I turn it over to Dave we do Joe one from Walter asking we see Concepts Concepts from functional languages becoming part of object oriented languages for example pattern matching C C sharp do you think that some of the concepts from Russ might be taken up by other languages yeah I definitely think so the bar Checker is the big one I know the newest versions of ADA recently Incorporated that I recently read a research paper about an attempt to Port the borrow Checker to C plus plus so it could be used before C plus plus code and they ultimately can decided there was it was too hard there was too many differences between the fundamental unchangeable parts of C plus plus and and the bar of Checker so you're unlikely to see a borrowed Checker in C plus plus although you probably will see uh safety models similar to that and then just a general question what kind of programs can you write with rust I would say that that uh given that Russ forces you to worry about the ball Checker and worry about your memory man but you're going to be using it to write the same kind of programs that c is ideal for right now so think of os kernels think embedded software where you know the the size of the program is critical the speed is critical and it should take as little memory as possible remember while the borrow Checker you know uh enforces safety requirements it's only at compile time and your program at runtime runs pretty much with the same speed and light footprint as a seed program does great next one we have from sushil asking has any modeling language been linked to rust for auto transformation of the model into code I don't think I know the answer to that question I'm going to bet that yes it has been done uh it's certainly pretty easy to take some modeling language and and as a front end and you know assuming that it auto-generates C you could probably just make change to Auto generate rust but I don't yet know of a project where that's been done yeah I'm kind of what Dave says I don't know of us I don't know for sure if that's been done either but there doesn't seem to be any reason it couldn't have been okay we are caught up on Q a so we can go on to uh David's sport thank you for that thanks Shane okay so uh Joe has already given us a good overview of Russ and what the security model uh protects us from and now I'm going to talk about the limitations of the security model uh every security model is limited uh partially it's limited because everyone has a slightly different notion of what what they want out of a security model so there's no way that that rust security model could satisfy everyone it might satisfy Joe and not satisfy me or vice versa or more likely uh it tries to satisfy you know the things that Joe and I have in common and that means that we're both slightly unhappy with it we both would have things that doesn't satisfy um but uh so we've already talked about the bog Checker I'll show you some borrow Checker limitations in a little bit uh places where the bar Checker uh um well it's problematic but the brow Checker also has limited scope it's limited to uh to memory safety and concurrency safety and with concurrency safety it's limited specifically to race conditions uh which we pretty much Define as uh concurrency safety over memory to make sure that no memory is accessed by two different threads at the same time but you could have other kinds of race conditions such as files being accessed over uh by two different threads at the same time and uh Russ does not handle that um so there's no reason why I rust program the C program couldn't have race condition over a file there's many other types of security problems and you can read all about them in our sort rules or in the say miter cwes uh you know SQL injection is one such type there's uh deserialization vulnerabilities Those are nasty in Java and Python and Ruby uh and then you can have other such programming bugs like floating Point exceptions if you expect if you expect to get the value 5.0 and you get 4.999995 well depending on what you're doing with that value you could have some serious problems and Russ does not help you with those and uh uh likewise of course there's lots of deprecated and obsolete uh algorithms on there md5 is one such example when I first heard of md5 I didn't even think of it as a cryptography algorithm it was just I was just told did your download complete prop properly uh if so then you should have the md5 hash uh the following nd5 hash you know and uh back then people were using it just for doing checksums and not for crypto but uh well if you if you're doing it for crypto now then you are using obsolete technology you're living in a state of sin go forth and sin no more okay so I'll move on to uh example of the limitations of the bar Checker now as Joe explained LeBron Checker is designed to uh to prevent any insecure uh source code from uh compiling so when the broad Checker has um errors or bugs or warts whatever you want to call them uh it airs on the side of caution and by that I mean it takes a perfectly valid program that would not have undefined behavior and it forbids the program from being compiled so what I have here in the slide is an example of C plus plus code that is uh perfectly safe and fine it's very similar to Joe's example in this case uh we're iterating over a vector and instead of adding a new element to the vector we're just changing one of the elements of the vector so whereas adding an element to a vector and C plus plus causes any iterator to become stale changing a vectors element does not you can change elements with linearly in your and your um and as long as this element number is the same your iterators are still good so this program compiles properly and runs and does exactly what you expect the analogous rust program however fails to compile and again while it looks to you and me that this program is well defined it would work properly it violates the borrowed Checker uh because again we are doing a uh an immutable borrow on the second line of factual code and then a mutable borrow on the fourth line of actual code and this is forbidden so the borrow Checker will stop you and not allow this program to compile so in other words the borrow Checker con gets in the way of what would otherwise be perfectly fine working code because the brow Checkers model is limited it is limited in that it's not limited in that it ever allows insecure code to compile it's limited in that it sometimes forbids secure code from compiling uh fortunately there are several workarounds you know if you really want to compile and run a program that does this stuff you can do things such as wrap your vector elements in a Cell in a in the uh cell class or you can use the split at new class or you can work with indices rather than iterators so you know there's there's several ways to skin this particular cat it's just that the way that we've done here violates the bio borrowed Checkers uh limitations and then it's worth mentioning all those work rounds are in a safe for us none of them open you up for the possibility of undefined Behavior or any bad things like that right right so this this particular program can be Rewritten correctly it's just that re writing the program this way shows the bar Checker imposes some excess limitations on on uh on the programmer so what I have here is uh simply an overview of uh the various security the classes of security problems and as you can see uh Java and python provide a bit more security guarantees than C provides and Russ provides a bit more on top of those because again the goal of rust was to obtain The Best of Both Worlds the security that you get in job on python but along with the performance that you get in C so uh uh I'll simply note again that the the security that Russ provides is not absolute you still have you know third-party code AS problems uh the injuries you get some protection against overflows because Russ can sometimes detect them I believe that's a switch you have to turn on when you're when you're building and rust code um so so again it's not a Panacea but it is a step in the right direction a few points worth bringing up here except for Andrew overflows there's two kinds of problems people think of when they think of that one is like unsigned integers and see where it wraps around and isn't undefined Behavior it could just be unexpected the other is like signed energy overflow and see which is undefined Behavior in Rust you're always safe from the undefined Behavior the only question is whether you want wraparound to happen or the air to be caught the other thing I wanted to call attention to is memory corruption and language like Java and python they have Escape hatches that will let you be Memory unsafe too just like Russ does in Java think jni or sundaught Mr unsafe and python think C types right in fact all three languages so the rest of it doesn't exactly have an escape hatch outside of rust you can't like say I'd like to write this part of rust in in C or assembler um but Russ does have unsafe for us when you want to do something that's unsafe well I think they did recently stabilize inline assembly actually and yes that's definitely unsafe blocks only right it's unsafe code uh so the to me I mean this this is interesting to me in that Javan python if they want to let you write unsafe stuff they'll let you drop down to the C and of course the Java developers are not responsible for the C language and neither the python developers the rust developers are responsible for unsafe rust but if you but they're not responsible for what happens in C or assembler right so if you want to call C from rust you have to write the unsafe code that does it and then any undefined behavior is your responsibility right so unsafe for us is simply them taking some responsibility for unsafe code that you write whereas if you go into C or or uh assembly yeah yes you're on your own okay um so I'll go ahead and ask for if there's any quick questions before I move on chain yeah we got one from Walter uh David and that is is there some cargo toll like clippy that would detect insecure code in Rust um I actually did talk about this uh coming up so I'll encourage Walter to stay tuned I will have a slide about static and dynamic analysis uh for rust code shortly okay we got one more from sushiro asking can all the unsafe slash insecure usages identified in this presentation be prevented through the concept of a safer subset of rust for example as in misra C well safe rust already is that it does prevent all the bad things we've talked about they're already all only possible and unsafe risk right there are some things like SQL injection that that rust doesn't prevent and if you want to prevent That Then I then you know you might stay away from working with a database if you have to work with a database then then Our advice is simply the same advice we would give if you're using Java or python or C which is uh you know don't just pass a string to uh your database you know use uh uh use a prepared string or a yeah both Java and python have statements prepared statements that's the phrase I was thinking of you know they have methods for building for safely building SQL statements with uh with sanitized data so that uh so that you can avoid SQL injection and Russ has these things too rust just isn't better than job R python at preventing escrow injection so the first order approximation everything that miseracy protects you from in C say Frost already protects you from okay so you just touched on this this might be Daniel's question it says uh Daniel asked the rust type system can be extended by third-party libraries for handling non-supported checks like SQL injection I mean in principle you could write a compeller plugin to do whatever you wanted or try to build a SQL library that only lets you use parameterized queries yes neither of those things are inherent to the language but it's definitely possible and they're probably already are third-party crates that do that okay we're caught up thank you guys thank you Shane okay so in this section um in this section we're going to basically uh this section is designed for uh system administrators and users people who are not rush developers the argument being that uh your system has to have some Rust program in it and you're concerned about these software about the Safety and Security of that software and you're not a rust developer so you can't necessarily fix any any vulnerabilities yourself so uh the good news of course is that Russ is getting more and more proper it's been accepted as a it's been accepted into the Linux kernel that is to say they will let people submit uh rust device drivers as a version uh 6.1 it's 6.2 6.2 right um it's also been added to uh UEFI so it'll appear in Microsoft Windows shortly there is of course the rusty compiler which is a front end too well the llvm and the uh the GCC folks are actually writing a rust front end to the GCC tool chain so this just simply shows that Russ is getting more and more adoption but that means that as it gets more and more adoption that the attack service of you know rust software is growing and there may soon be you know there may be rust code on your machine that that is insecure or they might soon arise some so how do you deal with that so uh we did a quick search on um on miter's website for cves that that involve rust and we came up with uh yeah uh 400 hits of cves you know vulnerability reports that involve rust code and these ran the usual gamut of security problems such as unsafe to your serialization uh uh they did include uh use Factor free and other and out of bounds rights which are memory problems those should have been caught by the broad Checker obviously these things escaped the borrow Checker and it's an open question as to why you can look at those individual CDs if you want um you know it's possible that there was a bug in the compiler more likely these might have been unsafe for us or they might have been you know rust interacting with C in some unsafe fashion right and most of these I can say it turned out were because of the use of unsafe rust virtually none of them were compiler bugs or soundness bugs that led to these okay so um so the point being of course that uh you know also these since these were a couple months ago then you know it stands reason that many of them will have been patched by now or by the time that you that you hear this so uh constantly the uh the fact that that Russ uh so Russ is less vulnerable than uh arrest programs are less vulnerable than C programs are less likely to be vulnerable but clearly they it can still happen and so we therefore need various analysis tools such as static and dynamic analysis so rust is a fairly new language and therefore uh what that means is that the the uh I guess you might say the market or the set of current analysis tools is still very embryonic you know there's uh there's uh I have here two tools uh rudra and Miri which are static and dynamic analysis tools for rust and they do find some some things I find very little part of the reason they find very little of course is that the bar Checker in Rust catches many errors that are caught by Sac analysis in C and Java so a lot of the work that static analysis tools have to do in older languages they don't have to do in Rust because the biotecher does it for them but that means there's still some things that they can do and that um so uh they well so they still have to do to check for some things like integer overflows and uh therefore we you know we have these story these tools available for now but they're still largely research and beta quality tools at this point uh one other thing we you can do with Russ is try to to uh reverse engineer rust code using uh ghidra or um or some other decompulation uh mechanism I will say that these tools are also at a in an embryonic State uh they have all we have a lot of experience with reverse engineering C code but rust used does some things differently than C on the assembler level uh for instance they might reorder their uh struct or class members um in order to to compact memory more and that's and see it doesn't have to do that so uh so there are challenges in terms of static and dynamic analysis and reverse engineering tools uh you know one thing I'll I'll conclude with here is somebody that rust is also starting to be used for malware and this might concern you so because that means they're going to make that that the well there's going to be more strong secure malware out there and that's a fair point I will add however that the that's a it's a fair point but it's a less scary Point than if the malware writers were not using reps at all and they decided that Russ was insecure not worth their effort so you know use rust because the malware users are doing it foreign all right so uh Shane I'll turn it again to any questions before we move on to overall stability and maturity or Tim uh I chimed in with asking I heard something about Polonius that should be able to allow more than the borrow Checker today to eliminate the limitations you mentioned to know more about this current status um I think I've heard the name Polonius I don't know anything else about it yet have you heard anything Joe it sounds familiar to me too but I cannot recall if it would fix the problems in this presentation or not okay that was all the only thing in there as of now it's good to know that there are people at least that these are problems that people are paying attention to and trying to solve you know hopefully next year we'll have we'll be able to say you know the you know the feel of static analysis is a little better now thanks to this new tool or thanks to this new project this is the nature of uh this is the nature of Technology things get better okay so um yeah the last major section I wanted to talk about was stability and maturity and well I start off this section thinking what the heck is maturity to me maturity simply means the language is Young And it simply means that my boss doesn't want me programming it because uh because it's immature and uh so I start so I basically sat down and came up with a list and uh the list is here of of aspects of a language that would contribute to it being considered mature so uh some of these are bureaucratic that there's a committee of some sort that maintains a language that the committee employs some sort of transparent mechanism for uh for issuing releases to the language and that the committee you know does some also surveys uh how widely used the language is uh a lot of that became easier in the in the open source era because we now have we now have uh open source repositories like Source Fortune GitHub and there's further more technical items such as you know a reference implementation um or a compliance test Suite that can tell you if your homegrown rust compiler is actually compatible with rust C and likewise a uh third party a repository of third-party libraries if you write an open source rust Library where can you work you publish it or where can you publish a C library so with these eight uh with these eight metrics I then applied them to see Java Python and rust and as you can see most of these metrics are supported by all four languages but you see if you see a interesting an interesting set of of gaps you know towards the bottom there you'll see that the C in Java are stronger when it comes to uh when it comes to the bureaucratic side they're stronger in in terms of having having official uh established committees you know seed standards committee is a subgroup of iso and John is this subgroup not of iso but of Oracle actually you know the Java Community processes it is quasi-independent of Oracle and the relationship between them is murky and that's all I can really tell you however Python and rust Excel not so much in the bureaucratic side but in the technological side both Python and rust have official repositories for third-party code you know Joe already mentioned crater for uh for rust or cargo sorry cargo crater these words all start to sound alike after a while um but but rust also has this interesting survey technology uh crater which I want to talk about a bit more because what they do what they do with it is every now and then I'm not sure if it's nightly or weekly it basically iterates through all of the published code open source code either on GitHub or uh cratesup.io and runs any it tries to build all the all the rust code there and price run internal tests and they use to test new features of the compiler and what they decide is if the new compiler a test fails but the test worked on the old on the old version of the compiler the stable version then they figure that they've either found a major compiler bug that they can fix or they may decide that that uh well they may realize that there's some broken code on up there rust code on GitHub or crates IO now the nice thing about that is that if they still want to run with their to to upgrade the compiler and break the code they can at least contact you you know if it's your code they can contact you and saying hey your code is using this version of rust or the rust compiler your code will no longer compile against the beta version uh would you like our help in in you know modifying your code to work with the let's say up to date with modern rust so so uh this is a way of stability of achieving stability in that you know if your code breaks and it's open source you'll get some help from the rust community and that's worth mentioning even that's the less common outcome usually unless they like find a soundness bug in a standard Library they're not going to break and then come to you to help fix it what usually happens when they find breakage like this is they realize they introduced one by accident and they'll fix that before the next stable release so no change to your code is needed at all right right this is usually a way of just detecting bugs while they're in their own inrocity itself um so another point for rustability is that uh most new languages that add new features as they go along uh they will have uh incompatible features or platform specific features that uh that they'll encourage you to use uh some some vendors who shall remain nameless have often used this as a way of locking people to using their own platform by encouraging you to use platform specific extensions so rust has the same problem and I use the term loosely because obviously for some vendors this is sort of an asset at vendor lock-in but Russ basically forces you to use you know the following syntax which is in the lower corner of the slide if you want to use a unstable feature so while you can use experimental features you can't do it without being being made aware of it make sure that you're potentially doing something unstable and one thing I'll add is in a addition to needing to use that feature annotation if you want these unstable features you then also need to build your code with a nightly compiler rather than a stable one so you're really opting into instability if you want it so it's never going to surprise you right it's very hard it's you know considerably harder to use the unstable nightly rust compiler than an unstable nightly say uh Jala or python interpreter um yeah one last thing I'll mention here is that uh the uh yeah the rust IO or you know the package repository has simply made a made a uh promise at least in that they are promised not to unpublish any stable code uh any stable rushed crates so you don't so you don't have to fear relying on a crate and suddenly the crate disappears and you can't use it anymore um you know Joe and I both remember the left pad Fiasco um which occurred in 2016 where um where the JavaScript repository I guess I think it's npm right they took down at the request of the offer they took down about 11 lines of JavaScript code which wound up breaking about half of the internet and Joe and I have also encountered this problem in uh using a certain Ruby on Rails gem as well so this problem can occur in in repositories if they allow code to be unpublished but rust is just but uh yeah like crazy forbids that from happening roughs if you publish something in Rust and it becomes stable then it's up there and you no longer have the right to to withhold it you can decide not to publish any more crates if you want but the ones that you are that you posted up there well they're there for good from now on you can mark them as deprecated but you can't remove them and then if you do mark one as deprecated that'll keep packages from adding it that didn't use it before but it'll always continue to be available for whatever already has used it right okay so um that's a quick conclusion of the uh of the maturity you have actually our conclusion was that there's two levels of maturity for rust depending on whether you're working with open source rust code or um proprietary uh closed source code if you're doing proprietary code that if you're not sharing it with anyone or you're sharing it only with you know a paying customer uh then you've got about the same level of maturity that you have with python that is a it's it's fine for the the version of rust that you're using however it might possibly break under new versions of rust it's unlikely they'll try to prevent that kind of thing but the rest developers you know can't help you or detect breakage in your code if they don't have access to it however if your code is open source and you publish it on GitHub or uh or crates IO then you would then your maturity level goes a good bit higher because the uh you can add tests to Simply say if this if this test ever breaks then that's a bug in the compiler or you know you're changing the compiler in an incompatible way right in effect if you make your code open source it becomes part of Rusty's test Suite exactly it becomes part of the test suite for rust C so this gives you a level of of stability maturity that's greater than python um it's still not quite at the level of C or Java yet and the reason I I give it lower marks than I give for C or Java is because right now you know rough C is a very good compiler but it's the only one if you want to compile rust code you have to use rust C eventually Russ will have uh there'll be a GCC front-end and that will be a second compiler and that will increase the ability a bit more because GCC or whatever they call their rust front end will have some variations between how what it accepts and what rust C accepts and that will force it will basically Force more stability it'll force them to agree on what parts of the language are what are specific to the Rusty compiler and what parts are our general so it will force them also to to write up a uh a written specification and probably have a test Suite as well that both GCC and rust C conform to I'll also point out C and Java aren't perfectly stable either just as quick examples of each and C removal of get ass even though it was super dangerous was still technically a breaking change removal of K and R function definitions another because there's edge cases where they can't be replaced even if they weren't still technically is Java the big one was back in Java 9. when they added the module system that broke a lot of uses of reflection needed new Flags like ad opens so The Benchmark here isn't perfect right well Perfection is an impossible dream in this in this world um and I'll just simply add that well I can still compile programs that have that use get us with the GCC so even though it's no longer in the last language it's still supported by the compilers for as long as they as they want to so um are there any more questions uh before we move on to the conclusion Shane we had one from earlier David asking how many cwes apply to unsafe rust so right when we did the search there was about 400 I think he said CW he's not CVS oh sorry um so yeah CWS are common weakness enumeration which are categories of vulnerabilities cves are are uh common vulnerability enumeration I'm not sure yeah the the two acronyms are very similar and very confusing cwes are language agnostic they're supposed to apply to every language um and although and there are a few that are specific to to certain languages but um so how the question was how many cwes could correspond unsafe for us correct so um it would stand the reason that the the the ones that are specifically about uh out of bounds memory reads or rights um are uh would be would not apply to rust you know you're losing a handful right there there are I know that I forget the numbers there are ones about data races that would also not apply um let me think a moment I also think any that are about pointers in particular will only be applicable and unsafe for us right yeah because safe for us prevents all mishandling appointers right so um I I know that I just discovered that there's a CBD number 1135 or so and you know the last I knew that CBS went up to a thousand I'm guessing there's only about one to two hundred ctoes but the number keeps keeps leaping up on me and growing so any answer I can give you now will probably be obviously next month all right we are caught up in the queue so if anybody has any further questions I know Dave's going to go to the conclusion now feel free to get them in there yep actually I'm going to tell us to turn the conclusion over to Joe okay yep so I'm gonna wrap us up here thanks Dave so yeah key takeaways yeah rest is a lot safer than C it's not perfect there's some kind of vulnerabilities programming languages will never be able to solve like if there's some administrative function and you forget to check to see if the user's administrator no language is going to catch that kind of thing pulling it's catching up really fast for how new rust is compared to see like 10 years old versus 50 that's a 40-year difference you wouldn't know it based on how close the tools are already I was mentioned before there's a lot of places like Linux kernel Windows kernel even Firefox using rust in production now I'll also mention one thing that's going to lead to a lot more rust in the Linux kernel is once GCC supports Russ bellinov then it'll work on a lot more architectures and then it can be used in a lot of the architecture independent places in Linux kernel right now llvm supporting fewer is kind of a Blocker on that um companies like Amazon and Google are using rest in production too I think this is enough examples here to show the world has accepted this as a commercial production-ready language it's not an experimental thing anymore so that's basically all we had so if you have any final questions Now's the Time if you have any later email address on the screen info sei.cmu.edu it'll get routed all one of us and I would like to give one quick shout out to Garrett Wasserman who helped us assemble uh this production this presentation in particular he was responsible for the uh rust Security in context talking about static analysis tools cves and so on so thank you Garrett David uh Joe great discussion today thank you very much for uh sharing your expertise it was great to be here Shay thank you thanks and we'd like to thank you all for attending today upon exiting we asked you hit the like button below the video window and share the archive if you found value also you can subscribe to our YouTube channel by clicking on the SEI seal in the lower right corner of the video window our next webcast will be August 9th the top will be what's wrong with Roi for model based analysis of cyber physical systems registration information is available on our website now and will be emailed out as well as David and Joe mentioned any question from today's event please send to info at sei.cmu.edu thanks everyone have a great day

Channel: Software Engineering Institute | Carnegie Mellon University

Views: 1,319

Keywords: Cybersecurity, Programming', Rust, Coding

Id: AYpoZ0oEoXU

Length: 53min 38sec (3218 seconds)

Published: Thu Jul 27 2023