6 ms·

That’s not true at all. 2 of the 3 biggest security vulnerabilities I’ve had to deal with in my career were completely unrelated and wouldn’t have been prevente

That’s not true at all. 2 of the 3 biggest security vulnerabilities I’ve had to deal with in my career were completely unrelated and wouldn’t have been prevented had software been written in Rust instead. Also half the software mentioned in that gist should never be used in security-focused applications anyway (if your depending on ‘cat’ or ‘awk’ to be bug free for your application to be hardened then you’re already doing it wrong)

bluGill 5y ago
I use cat and awk in my build system. I can imagine bugs in either that I wouldn't notice in general that would compromise my application. They are off the wall enough that I don't think they have ever happened, but my application is an embedded system that has the ability to kill people so I'm a little paranoid. (not so much that I don't use awk in my build system where it is a useful tool)
- laumars 5y ago
  My point was if you’re exposing your build system to untrusted individuals inputting untrusted data then you’ve already lost the game. Rust won’t save you from a RCE bug because you’ve already granted them RCE from the beginning. An overflow bug in awk is only exploitable if someone can craft input into awk. And if you’re allowing people to do that then you’ve already given them access to remotely run code without them needing a bug.
  - staticassertion 5y ago
    > My point was if you’re exposing your build system to untrusted individuals inputting untrusted data then you’ve already lost the game. This is how the vast majority of build systems are configured. If I have owned a dev and can push code to a branch I can likely execute code in their build environment. If they then parse that build output with something like awk, that's attack surface. Is it the first thing I'd try to attack? Nope. But I do wonder what the cumulative impact of every binary on your system being memory safe would be. I'd definitely feel better.
    - laumars 5y ago
      > If I have owned a dev and can push code to a branch I can likely execute code in their build environment. But then you’re also executing that code as a trusted user. Ie the real hack is owning the dev. > This is how the vast majority of build systems are configured. No. The vast majority of build systems are either locked to private repositories, and/or a subset of developers, and/or run in an ephemeral sandbox. > But I do wonder what the cumulative impact of every binary on your system being memory safe would be. I’d already answered that. It’s negligible because if someone can exploit a buffer overflow in awk then they can already run arbitrary code in awk (remember, awk is a programming language). So if you’re not already taking precautions about who is running what on your build system and how running code is sandboxes then it’s not going to take a buffer overflow bug to RCE it.
      - staticassertion 5y ago
        > But then you’re also executing that code as a trusted user. Ie the real hack is owning the dev. That's like saying the real hack is sending a phishing email, ignoring all privesc, lateral movement, etc. > No. The vast majority of build systems are either locked to private repositories, and/or a subset of developers, and/or run in an ephemeral sandbox. I didn't say otherwise. I said that the majority allow untrusted execution. If you consider your engineers laptops to be trusted you're thinking about networks the way people did ~10+ years ago. > It’s negligible because if someone can exploit a buffer overflow in awk then they can already run arbitrary code in awk This isn't true, but even if it were you can just replace awk with anything else that's not turing complete.
        laumars 5y ago
        > I said that the majority allow untrusted execution. If you consider your engineers laptops to be trusted you're thinking about networks the way people did ~10+ years ago. i never said anything about trusting engineers laptops. Let me put it another way, are you running your build pipelines bare metal, allowing anyone to instantiate the pipeline against a branch of code that anyone in the public has written? Or is that build pipeline running against a private repository, or triggered by trusted users, or does it run inside a temporary VM or container that gets destroyed afterwards? That’s where you harden CI/CD. I’m not suggesting fixing buffer overflows aren’t worthwhile (security should be multilayered after all) but it’s missing the real risk since you’ve already got code remotely executing. Thus your threat model should be about ensuring you minimise the blast radius of that code. To use your colourful language: if your build pipelines are running bare metal then you’re thinking about infra like people did ~10 years ago. > This isn't true, but even if it were you can just replace awk with anything else that's not turing complete. But you’re still not addressing the real issue. If you can’t trust the the code executing and you’re not sandboxing that code then you’ve already lost the fight. You can’t give unrestricted access to execute code remotely and then moan “we wouldn’t have been exploited if everything was written in Rust”. The bone headed design was allowing unrestricted remote code execution and not the buffer overflow bug in ‘cat’. > That's like saying the real hack is sending a phishing email, ignoring all privesc, lateral movement, etc. It’s really not. What I’m taking about is the equivalent of saying “phishing attacks are always going to happen so you need MFA et al to harden against the array of of ways one can manipulate the system” You’re entire security model seems to be focused around fixing every fucking executable against every possible class of bug and that’s insanely impractical. Whereas I’m suggesting one shouldn’t implicitly trust remote code in build pipelines to begin with.
  - bluGill 5y ago
    There are more bugs than just overflow bugs. See reflections on trusting trust https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-tho... for example.
    - laumars 5y ago
      That’s literally the point I’m making.
lmm 5y ago
> 2 of the 3 biggest security vulnerabilities I’ve had to deal with in my career were completely unrelated and wouldn’t have been prevented had software been written in Rust instead. The last study I saw was that 52% of security vulnerabilities were still basic memory safety vulnerabilities. Memory safety isn't the only thing, but it's still the biggest thing. > (if your depending on ‘cat’ or ‘awk’ to be bug free for your application to be hardened then you’re already doing it wrong) People run cat or awk on log files (where an attacker could easily craft particular data patterns) all the time. Maybe they shouldn't, but they do.
- laumars 5y ago
  > The last study I saw was that 52% of security vulnerabilities were still basic memory safety vulnerabilities. Memory safety isn't the only thing, but it's still the biggest thing. My point wasn’t that memory safety isn’t a big issue. It’s that it’s not the only cause of vulnerabilities. Assuming your 52% figure is accurate (and I’m happy to take your word on that) that still means that roughly half of all vulnerabilities are not memory safety. Which means your figure actually just reinforces my point. > People run cat or awk on log files (where an attacker could easily craft particular data patterns) all the time. Maybe they shouldn't, but they do. I think there’s enough obscurity there hidden from the attacker that such usage should be safe from all but the most determined of attacker. And even then, they’d likely need some other attack to probe for usage about what systems are listening to what logs and using which POSIX utils that you could argue the attacker already has the access they need without going to the pain of crafting an overflow bug in a log file. Im not saying those bugs don’t exist nor shouldn’t be addressed, I’m just being pragmatic about their exploitability. The bigger issue is CI/CD pipelines. Often they’re define in the same mono-repo as the source itself and they’ll have execution rights automatically because that’s literally their function as a build and test pipeline. But because said pipelines are already visible and already executable, you need to have greater controls around that pipeline to prevent abuse otherwise it’s already game over even without an overflow bug.
  - lmm 5y ago
    > Assuming your 52% figure is accurate (and I’m happy to take your word on that) that still means that roughly half of all vulnerabilities are not memory safety. Sure, but that half is every other category of bug put together. I guess if your model is that every other class of bug will be significantly increased by a rewrite then maybe that logic makes sense, but that seems unlikely to me.

bluGill 5y ago

I use cat and awk in my build system. I can imagine bugs in either that I wouldn't notice in general that would compromise my application. They are off the wall enough that I don't think they have ever happened, but my application is an embedded system that has the ability to kill people so I'm a little paranoid. (not so much that I don't use awk in my build system where it is a useful tool)

laumars 5y ago
My point was if you’re exposing your build system to untrusted individuals inputting untrusted data then you’ve already lost the game. Rust won’t save you from a RCE bug because you’ve already granted them RCE from the beginning. An overflow bug in awk is only exploitable if someone can craft input into awk. And if you’re allowing people to do that then you’ve already given them access to remotely run code without them needing a bug.
- staticassertion 5y ago
  > My point was if you’re exposing your build system to untrusted individuals inputting untrusted data then you’ve already lost the game. This is how the vast majority of build systems are configured. If I have owned a dev and can push code to a branch I can likely execute code in their build environment. If they then parse that build output with something like awk, that's attack surface. Is it the first thing I'd try to attack? Nope. But I do wonder what the cumulative impact of every binary on your system being memory safe would be. I'd definitely feel better.
  - laumars 5y ago
    > If I have owned a dev and can push code to a branch I can likely execute code in their build environment. But then you’re also executing that code as a trusted user. Ie the real hack is owning the dev. > This is how the vast majority of build systems are configured. No. The vast majority of build systems are either locked to private repositories, and/or a subset of developers, and/or run in an ephemeral sandbox. > But I do wonder what the cumulative impact of every binary on your system being memory safe would be. I’d already answered that. It’s negligible because if someone can exploit a buffer overflow in awk then they can already run arbitrary code in awk (remember, awk is a programming language). So if you’re not already taking precautions about who is running what on your build system and how running code is sandboxes then it’s not going to take a buffer overflow bug to RCE it.
    - staticassertion 5y ago
      > But then you’re also executing that code as a trusted user. Ie the real hack is owning the dev. That's like saying the real hack is sending a phishing email, ignoring all privesc, lateral movement, etc. > No. The vast majority of build systems are either locked to private repositories, and/or a subset of developers, and/or run in an ephemeral sandbox. I didn't say otherwise. I said that the majority allow untrusted execution. If you consider your engineers laptops to be trusted you're thinking about networks the way people did ~10+ years ago. > It’s negligible because if someone can exploit a buffer overflow in awk then they can already run arbitrary code in awk This isn't true, but even if it were you can just replace awk with anything else that's not turing complete.
      - laumars 5y ago
        > I said that the majority allow untrusted execution. If you consider your engineers laptops to be trusted you're thinking about networks the way people did ~10+ years ago. i never said anything about trusting engineers laptops. Let me put it another way, are you running your build pipelines bare metal, allowing anyone to instantiate the pipeline against a branch of code that anyone in the public has written? Or is that build pipeline running against a private repository, or triggered by trusted users, or does it run inside a temporary VM or container that gets destroyed afterwards? That’s where you harden CI/CD. I’m not suggesting fixing buffer overflows aren’t worthwhile (security should be multilayered after all) but it’s missing the real risk since you’ve already got code remotely executing. Thus your threat model should be about ensuring you minimise the blast radius of that code. To use your colourful language: if your build pipelines are running bare metal then you’re thinking about infra like people did ~10 years ago. > This isn't true, but even if it were you can just replace awk with anything else that's not turing complete. But you’re still not addressing the real issue. If you can’t trust the the code executing and you’re not sandboxing that code then you’ve already lost the fight. You can’t give unrestricted access to execute code remotely and then moan “we wouldn’t have been exploited if everything was written in Rust”. The bone headed design was allowing unrestricted remote code execution and not the buffer overflow bug in ‘cat’. > That's like saying the real hack is sending a phishing email, ignoring all privesc, lateral movement, etc. It’s really not. What I’m taking about is the equivalent of saying “phishing attacks are always going to happen so you need MFA et al to harden against the array of of ways one can manipulate the system” You’re entire security model seems to be focused around fixing every fucking executable against every possible class of bug and that’s insanely impractical. Whereas I’m suggesting one shouldn’t implicitly trust remote code in build pipelines to begin with.
- bluGill 5y ago
  There are more bugs than just overflow bugs. See reflections on trusting trust https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-tho... for example.
  - laumars 5y ago
    That’s literally the point I’m making.

lmm 5y ago

> 2 of the 3 biggest security vulnerabilities I’ve had to deal with in my career were completely unrelated and wouldn’t have been prevented had software been written in Rust instead. The last study I saw was that 52% of security vulnerabilities were still basic memory safety vulnerabilities. Memory safety isn't the only thing, but it's still the biggest thing. > (if your depending on ‘cat’ or ‘awk’ to be bug free for your application to be hardened then you’re already doing it wrong) People run cat or awk on log files (where an attacker could easily craft particular data patterns) all the time. Maybe they shouldn't, but they do.

laumars 5y ago
> The last study I saw was that 52% of security vulnerabilities were still basic memory safety vulnerabilities. Memory safety isn't the only thing, but it's still the biggest thing. My point wasn’t that memory safety isn’t a big issue. It’s that it’s not the only cause of vulnerabilities. Assuming your 52% figure is accurate (and I’m happy to take your word on that) that still means that roughly half of all vulnerabilities are not memory safety. Which means your figure actually just reinforces my point. > People run cat or awk on log files (where an attacker could easily craft particular data patterns) all the time. Maybe they shouldn't, but they do. I think there’s enough obscurity there hidden from the attacker that such usage should be safe from all but the most determined of attacker. And even then, they’d likely need some other attack to probe for usage about what systems are listening to what logs and using which POSIX utils that you could argue the attacker already has the access they need without going to the pain of crafting an overflow bug in a log file. Im not saying those bugs don’t exist nor shouldn’t be addressed, I’m just being pragmatic about their exploitability. The bigger issue is CI/CD pipelines. Often they’re define in the same mono-repo as the source itself and they’ll have execution rights automatically because that’s literally their function as a build and test pipeline. But because said pipelines are already visible and already executable, you need to have greater controls around that pipeline to prevent abuse otherwise it’s already game over even without an overflow bug.
- lmm 5y ago
  > Assuming your 52% figure is accurate (and I’m happy to take your word on that) that still means that roughly half of all vulnerabilities are not memory safety. Sure, but that half is every other category of bug put together. I guess if your model is that every other class of bug will be significantly increased by a rewrite then maybe that logic makes sense, but that seems unlikely to me.