4 ms·

Wouldn't any memory-safe language help prevent this NULL pointer access? Why are all these crucial pieces still written in C/C++, when it's obvious to anybody k

Wouldn't any memory-safe language help prevent this NULL pointer access? Why are all these crucial pieces still written in C/C++, when it's obvious to anybody keeping even remote track of CVEs that these languages are just not up to the task with today's climate of a 24/7 shadow internet war? (The one that's likely been going on for at least 25 years at this point?) When will we learn? You hate Rust -- fine (not fine but OK, I guess people get super triggered over it and it's a reality I can't change but I am still baffled by it because they throw away reason for emotions and these people should really know better). Fine. Just use Golang or any other GC language really (Java or C# as well, if you must). When will we abandon convenient routine and start adapting to modern realities? ("Modern" being at least 25-year old here but hey, I am willing to give you some leeway and not roast you too much. Let's assume these are "modern" realities, f.ex. just the last 5 years.)

imranhou 2y ago
Windows does not support drivers based on rust language, so perhaps may be another 5 years
- pdimitar 2y ago
  Rust can't compile DLLs? AFAIK it can?
  - cmrdporcupine 2y ago
    This is a kernel driver. Runs in kernel space. Intercepts syscalls. You'd definitely be fighting uphill to write it in Rust. And your code would be riddled with `unsafe` by necessity anyways.
    - pdimitar 2y ago
      Fair enough, still Rust's unsafe is not dropping all of its guarantees. Quite a lot of them remain in place. Not saying you can't write bugs in Rust, of course -- that would be crazily delusional. I am saying they needed a better process. And I am saying that a stricter language could have improved the process a bit as well.
  - Filligree 2y ago
    Look at Linux. Getting Rust to work with the kernel is a long story of defining APIs, cleaning up the C-side API to make it tenable, coding test filesystems and whatnot to make sure it all works, and getting buy-in and maintenance for all of the above. Doing the same with zero control over the non-Rust side of the kernel seems completely untenable.
    - pdimitar 2y ago
      I am not saying there are no challenges. I am saying that CrowdStrike does not seem to have even tried to have a better process. Rust would be only a small part of the picture; just one more layer in the security posture (a small one at that, admittedly).
      - lambdaone 2y ago
        Exactly. It's like the brown M&Ms in the Van Halen rider; it's not that the M&M's were the problem, but that it was a test of diligence. People who don't care about detail are likely to screw up the big things just as badly as they screw up the little things. Being a multi-million dollar company and using unsafe languages today is not a good look. But everyone gets away with it because everyone else is doing it.
- bckr 2y ago
  How can that be possible? Are drivers not binary files?
- lowleveldesign 2y ago
  You can write drivers in Rust - it's just quite hard at the moment. Microsoft published metadata packages for WDK APIs and started creating samples: https://github.com/microsoft/Windows-rust-driver-samples https://github.com/microsoft/Windows-rust-driver-samples
  - lambdaone 2y ago
    Good. Microsoft doing something sensible.
cmrdporcupine 2y ago
My understanding is this was not a case of null pointer access that could be caught by a compiler really... but of a corrupt data file making a mess all over the place... running in kernel space, where no segfault is safe. The root issue is giving privileged access to a business entity you think you can trust, but clearly can't. I'm a fulltime Rust developer, but I don't think Rust saves you here.
- pdimitar 2y ago
  If what you say is true -- OK. Then would you say that the tweet posted earlier that showed the NULL pointer access was incorrect or misleading?
  - cmrdporcupine 2y ago
    Null pointer access caused by bad data is entirely conceivable... esp when you overwrite parts of kernel memory with nulls.
    - pdimitar 2y ago
      I see. That doesn't make it better though, and OK let's forget about other languages. I mean that the least you can do before pointer dereference is just check for several bad sentinel values, NULL being one of them. Seems like a rather amateur mistake to me.
      - lambdaone 2y ago
        From that point of view, there are several million amateurs, some of them quite highly paid, out there writing terrible code.
        pdimitar 2y ago
        Well, that statement is 100% true. I've been an idiot as well in the past. Happily some of us actually learn though!
aninteger 2y ago
We're all waiting for your anti-malware Rust Win32 kernel module... Ok, but seriously I don't believe this will ever happen and I don't really think this is a language debate nor do I want to engage in one. This is about putting critical infrastructure connected to the internet that's running an operating system that you can't trust out of the box. Since the Windows OS is susceptible to so much malware you need all these third party services (which you also can't trust or audit, but it's absolutely better than not having anything) on top of the OS. There was a whole host of companies that had zero problems, not because they're using Rust, but because they have much better security practices and quality infosec employees.
- pdimitar 2y ago
  > This is about putting critical infrastructure connected to the internet that's running an operating system that you can't trust out of the box. Since the Windows OS is susceptible to so much malware you need all these third party services (which you also can't trust or audit, but it's absolutely better than not having anything) on top of the OS. Agreed, they should not be using Windows in the first place. That should have been the first line of defense. > There was a whole host of companies that had zero problems, not because they're using Rust, but because they have much better security practices and quality infosec employees. Fair enough, I only commented on one layer of the security stack -- so your remark that expands the scope is valid and welcome. > We're all waiting for your anti-malware Rust Win32 kernel module... I am done working for free. If I am paid to do it I am sure I would have done better than this poor confused soul who allows NULL pointer dereferencing which is a mistake that most C/C++ interns quickly learn to avoid.
  - johnfonesca 2y ago
    >Agreed, they should not be using Windows in the first place Crowdstrike borked RHEL 1 month ago https://access.redhat.com/solutions/7068083 https://access.redhat.com/solutions/7068083 Literally the same situation, unbootable machines. The reality is that shitty software broke everything. Why do we have to drag the OS into this?
vb-8448 2y ago
A safer language like RUST won't help you against bad practices and poor QA processes. This is a kind of error that you should catch with automating testing, even before pushing the change to main branch.
- pdimitar 2y ago
  I agree. My point was that using a language whose compiler will not allow you to build your production binary if you make a certain mistake could have been one extra line of defense and who knows, that might have prevented this problem this one particular time. But I am in full agreement with you that sloppy programmers cannot truly be helped. They just screw up and move on like nothing happened. Sigh.
  - PartiallyTyped 2y ago
    You can still do unsafe, and you do need unsafe in some cases.
    - pdimitar 2y ago
      OK, sure, but don't you think that being a world-wide antivirus vendor should have warranted a better process?
      - PartiallyTyped 2y ago
        Oh absolutely. This is utterly unacceptable. The ease with which CS pushed willy nilly a bad build to prod in what seems to be a monophasic release is absurd. Something of this nature would have had our entire team fired. The number of phases and the thoroughness and exhaustiveness of the protocols we have to ensure we don't push bad builds would have most engineers taken aback... but we have to. With great power comes great responsibility.
    - lambdaone 2y ago
      And human beings can indeed write safe "unsafe" code. But to do so consistently, you have to be very smart, very cautious, and somewhat lucky.
trustno2 2y ago
You can do bugs in any language. The problem here was monoculture and critical dependence on one supplier, not a programming language choice
- pdimitar 2y ago
  I'd argue it's several things, these two things included. To screw up so legendarily requires a concert of bad decisions.
  - lambdaone 2y ago
    Yes. The term "normalization of deviance" comes to mind. Even just a phased rollout would have caught this one with just a tiny fraction of the damage observed.
- lambdaone 2y ago
  You can indeed write buggy/unsafe code in any language. But it's a lot easier to do in notoriously unsafe languages like C/C++, which for some maniacal reason we seem to have based the world's digital infrastructure on. C++ was a terrible, terrible mistake.
jmull 2y ago
Your plan is to replace all the software written in C/C++ with... software that doesn't exist. It's good to criticize the current state of things, but don't pretend you have a solution. Also, do we know if rust would have helped here? Rust doesn't guarantee no crashes -- in fact, panicking (aka crashing) is the default.
- pdimitar 2y ago
  From what I've seen, it was a NULL pointer dereferencing. Dynamic, not static, so still requires diligence even in Rust. RE: panic default, don't get fooled by hobby projects, professional Rust code always does pattern matching and does not defer to panics. The "software that doesn't exist" point is somewhat valid, though it's also the chicken and the egg problem, as in that not many people are working to make it happen because the current state of affairs is wrongly deemed as good enough. And it really is not.
  - jmull 2y ago
    > RE: panic default, don't get fooled by hobby projects, professional Rust code always does pattern matching and does not defer to panics. That's a "programmers who know what they're doing don't make that mistake" argument. If that were tenable there'd be no need for rust in the first place.
    - pdimitar 2y ago
      Yeah I don't disagree, you do have a point. But this is easier to scan for compared to all the potential memory unsafeties in C/C++. It's an improvement.
layer8 2y ago
1. It wasn't a null pointer: https://xcancel.com/patrickwardle/status/1814343502886477857 https://xcancel.com/patrickwardle/status/1814343502886477857 2. If the driver crashed due to a Rust panic, the result (boot loop) would be the same.

imranhou 2y ago

Windows does not support drivers based on rust language, so perhaps may be another 5 years

pdimitar 2y ago
Rust can't compile DLLs? AFAIK it can?
- cmrdporcupine 2y ago
  This is a kernel driver. Runs in kernel space. Intercepts syscalls. You'd definitely be fighting uphill to write it in Rust. And your code would be riddled with `unsafe` by necessity anyways.
  - pdimitar 2y ago
    Fair enough, still Rust's unsafe is not dropping all of its guarantees. Quite a lot of them remain in place. Not saying you can't write bugs in Rust, of course -- that would be crazily delusional. I am saying they needed a better process. And I am saying that a stricter language could have improved the process a bit as well.
- Filligree 2y ago
  Look at Linux. Getting Rust to work with the kernel is a long story of defining APIs, cleaning up the C-side API to make it tenable, coding test filesystems and whatnot to make sure it all works, and getting buy-in and maintenance for all of the above. Doing the same with zero control over the non-Rust side of the kernel seems completely untenable.
  - pdimitar 2y ago
    I am not saying there are no challenges. I am saying that CrowdStrike does not seem to have even tried to have a better process. Rust would be only a small part of the picture; just one more layer in the security posture (a small one at that, admittedly).
    - lambdaone 2y ago
      Exactly. It's like the brown M&Ms in the Van Halen rider; it's not that the M&M's were the problem, but that it was a test of diligence. People who don't care about detail are likely to screw up the big things just as badly as they screw up the little things. Being a multi-million dollar company and using unsafe languages today is not a good look. But everyone gets away with it because everyone else is doing it.
bckr 2y ago
How can that be possible? Are drivers not binary files?
lowleveldesign 2y ago
You can write drivers in Rust - it's just quite hard at the moment. Microsoft published metadata packages for WDK APIs and started creating samples: https://github.com/microsoft/Windows-rust-driver-samples https://github.com/microsoft/Windows-rust-driver-samples
- lambdaone 2y ago
  Good. Microsoft doing something sensible.

cmrdporcupine 2y ago

My understanding is this was not a case of null pointer access that could be caught by a compiler really... but of a corrupt data file making a mess all over the place... running in kernel space, where no segfault is safe. The root issue is giving privileged access to a business entity you think you can trust, but clearly can't. I'm a fulltime Rust developer, but I don't think Rust saves you here.

pdimitar 2y ago
If what you say is true -- OK. Then would you say that the tweet posted earlier that showed the NULL pointer access was incorrect or misleading?
- cmrdporcupine 2y ago
  Null pointer access caused by bad data is entirely conceivable... esp when you overwrite parts of kernel memory with nulls.
  - pdimitar 2y ago
    I see. That doesn't make it better though, and OK let's forget about other languages. I mean that the least you can do before pointer dereference is just check for several bad sentinel values, NULL being one of them. Seems like a rather amateur mistake to me.
    - lambdaone 2y ago
      From that point of view, there are several million amateurs, some of them quite highly paid, out there writing terrible code.
      - pdimitar 2y ago
        Well, that statement is 100% true. I've been an idiot as well in the past. Happily some of us actually learn though!

aninteger 2y ago

We're all waiting for your anti-malware Rust Win32 kernel module... Ok, but seriously I don't believe this will ever happen and I don't really think this is a language debate nor do I want to engage in one. This is about putting critical infrastructure connected to the internet that's running an operating system that you can't trust out of the box. Since the Windows OS is susceptible to so much malware you need all these third party services (which you also can't trust or audit, but it's absolutely better than not having anything) on top of the OS. There was a whole host of companies that had zero problems, not because they're using Rust, but because they have much better security practices and quality infosec employees.

pdimitar 2y ago
> This is about putting critical infrastructure connected to the internet that's running an operating system that you can't trust out of the box. Since the Windows OS is susceptible to so much malware you need all these third party services (which you also can't trust or audit, but it's absolutely better than not having anything) on top of the OS. Agreed, they should not be using Windows in the first place. That should have been the first line of defense. > There was a whole host of companies that had zero problems, not because they're using Rust, but because they have much better security practices and quality infosec employees. Fair enough, I only commented on one layer of the security stack -- so your remark that expands the scope is valid and welcome. > We're all waiting for your anti-malware Rust Win32 kernel module... I am done working for free. If I am paid to do it I am sure I would have done better than this poor confused soul who allows NULL pointer dereferencing which is a mistake that most C/C++ interns quickly learn to avoid.
- johnfonesca 2y ago
  >Agreed, they should not be using Windows in the first place Crowdstrike borked RHEL 1 month ago https://access.redhat.com/solutions/7068083 https://access.redhat.com/solutions/7068083 Literally the same situation, unbootable machines. The reality is that shitty software broke everything. Why do we have to drag the OS into this?

vb-8448 2y ago

A safer language like RUST won't help you against bad practices and poor QA processes. This is a kind of error that you should catch with automating testing, even before pushing the change to main branch.

pdimitar 2y ago
I agree. My point was that using a language whose compiler will not allow you to build your production binary if you make a certain mistake could have been one extra line of defense and who knows, that might have prevented this problem this one particular time. But I am in full agreement with you that sloppy programmers cannot truly be helped. They just screw up and move on like nothing happened. Sigh.
- PartiallyTyped 2y ago
  You can still do unsafe, and you do need unsafe in some cases.
  - pdimitar 2y ago
    OK, sure, but don't you think that being a world-wide antivirus vendor should have warranted a better process?
    - PartiallyTyped 2y ago
      Oh absolutely. This is utterly unacceptable. The ease with which CS pushed willy nilly a bad build to prod in what seems to be a monophasic release is absurd. Something of this nature would have had our entire team fired. The number of phases and the thoroughness and exhaustiveness of the protocols we have to ensure we don't push bad builds would have most engineers taken aback... but we have to. With great power comes great responsibility.
  - lambdaone 2y ago
    And human beings can indeed write safe "unsafe" code. But to do so consistently, you have to be very smart, very cautious, and somewhat lucky.

trustno2 2y ago

You can do bugs in any language. The problem here was monoculture and critical dependence on one supplier, not a programming language choice

pdimitar 2y ago
I'd argue it's several things, these two things included. To screw up so legendarily requires a concert of bad decisions.
- lambdaone 2y ago
  Yes. The term "normalization of deviance" comes to mind. Even just a phased rollout would have caught this one with just a tiny fraction of the damage observed.
lambdaone 2y ago
You can indeed write buggy/unsafe code in any language. But it's a lot easier to do in notoriously unsafe languages like C/C++, which for some maniacal reason we seem to have based the world's digital infrastructure on. C++ was a terrible, terrible mistake.

jmull 2y ago

Your plan is to replace all the software written in C/C++ with... software that doesn't exist. It's good to criticize the current state of things, but don't pretend you have a solution. Also, do we know if rust would have helped here? Rust doesn't guarantee no crashes -- in fact, panicking (aka crashing) is the default.

pdimitar 2y ago
From what I've seen, it was a NULL pointer dereferencing. Dynamic, not static, so still requires diligence even in Rust. RE: panic default, don't get fooled by hobby projects, professional Rust code always does pattern matching and does not defer to panics. The "software that doesn't exist" point is somewhat valid, though it's also the chicken and the egg problem, as in that not many people are working to make it happen because the current state of affairs is wrongly deemed as good enough. And it really is not.
- jmull 2y ago
  > RE: panic default, don't get fooled by hobby projects, professional Rust code always does pattern matching and does not defer to panics. That's a "programmers who know what they're doing don't make that mistake" argument. If that were tenable there'd be no need for rust in the first place.
  - pdimitar 2y ago
    Yeah I don't disagree, you do have a point. But this is easier to scan for compared to all the potential memory unsafeties in C/C++. It's an improvement.

layer8 2y ago

1. It wasn't a null pointer: https://xcancel.com/patrickwardle/status/1814343502886477857 https://xcancel.com/patrickwardle/status/1814343502886477857 2. If the driver crashed due to a Rust panic, the result (boot loop) would be the same.