undefined | Better HN

0 pointsbluGill5y ago0 comments

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)

0 comments

5 comments · 1 top-level

laumars5y ago· 4 in thread

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.

staticassertion5y 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.

laumars5y 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.

1 more reply

bluGillOP5y ago

There are more bugs than just overflow bugs. See reflections on trusting trust https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-tho... for example.

laumars5y ago

That’s literally the point I’m making.

j / k navigate · click thread line to collapse

0 comments

5 comments · 1 top-level

laumars5y ago· 4 in thread

staticassertion5y ago

> My point was if you’re exposing your build system to untrusted individuals inputting untrusted data then you’ve already lost the game.

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.

laumars5y 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.

1 more reply

bluGillOP5y ago

There are more bugs than just overflow bugs. See reflections on trusting trust https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-tho... for example.

laumars5y ago

That’s literally the point I’m making.

j / k navigate · click thread line to collapse