6 ms·

I control a fleet of servers. I have a saltstack or ansible script. One of the steps in provisioning a new server is to pull library X from github.com. One day

I control a fleet of servers. I have a saltstack or ansible script. One of the steps in provisioning a new server is to pull library X from github.com. One day Egor Homakov finds a new hack and finds his way into access to the master branch for library X. As a prank, he force pushes a change to master. Being aware of such a possibility, instead of setting up my script to pull from master or even a specific tag, perhaps I pull from a specific sha1sum. That way I know I'm getting the exact version I want. That's today. Tomorrow, when preimage SHA-1 attacks are cheap, it will no longer save me.

stonogo 10y ago
Sounds like sentence three is where you got it wrong. You should be pulling your software to a development host, building it after verification, and uploading the deployment package to an artifact repository inside your security perimeter. Sentence three becomes 'pull library X from my artifact server.' There is no way to securely deploy a package directly from the internet. The sooner you understand that, the sooner you'll be able to sleep through needless catastrophes like this hypothetical attack -- or leftpad.js.
- amingilani 10y ago
  Either way he'd be pulling from Github.com at some point, whether in the build environment or production. He won't ever know that the repository was compromised. Besides, some people use Heroku simply to deploy their rails or node apps, and they don't have an artefacts server.
- Perseids 10y ago
  > There is no way to securely deploy a package directly from the internet. Fetching a file from the internet and verifying it against a hash or signature is the only way to securely deploy a package from the internet. This is exactly one of the use cases theses cryptographic primitives are built for. Don't blame the users when they utilize the tools the way they are supposed to be, blame the tools when they fail when doing so. And by the way, if you ever need to run `apt-get upgrade` or `apt-get install` on your production server from a public mirror, then you are guilty of "deploying a package directly from the internet", too. (My apologies and congratulations if don't.)
  - raverbashing 10y ago
    apt-get can (and do) check signatures of repos But yeah, you could put an unverified repos to be used
    - lmm 10y ago
      Git has tag signing, surely there's a way to clone a specific tag and check the signature against a specific GPG key fingerprint?
      - heartsucker 10y ago
        git checkout 0.1.0 git tag -v 0.1.0
      - nhaehnle 10y ago
        Tag signatures only cover the mapping from tag name to commit hash. In other words, specifying a manually-verified commit hash is actually more secure. Tag signatures are mostly worthless now from a crypto point of view -- with the caveat that you can still get some value from them if you still trust sha1 to be secure against second-preimage attacks.
    - Perseids 10y ago
      For the argument at hand (Can you deploy anything on a production server from a third party that is only verified cryptographically?) signatures and hashes fulfill the same function (and btw I also wrote "verifying it against a hash or signature" above). More to the point, under the hood GPG signatures only sign a hash of the file in question anyway. Verifying a file via a GPG signature is strictly less secure than verifying it by its hash (assuming you use the same hash function as the signature).
hasenj 10y ago
If you want a specific hash, why pull it from github everytime?
- falsedan 10y ago
  Because, when provisioning a new server, where else can you get it from?
  - dozzie 10y ago
    From a custom package you have built? Did you know that RPMs and DEBs don't grow on magical trees, but are built?
    - throwayguestman 10y ago
      So, the problem still stands, theoretically. Not only do you likely need to populate your host with packages not from your host. But also, your host will also still be connect to a public net, even if only indirectly (e.g. private net), and hence potentially manipulated.
      - dozzie 10y ago
        No, you misunderstood what is actually the problem here. Pulling under deployment some code from random resource from the internets that can go down or get deleted at a whim and you can't easily move to just some other mirror and you don't even control when the thing will be up back, that's the problem. Not the trust you need to put to use the code (this is still there, obviously). And the very same comment applies to third-party package repositories, like PPAs in Ubuntu. Not to mention that with pre-built binary packages your deployment speed and repeatability get significantly better, as you don't need to rebuild the artifacts every single time.
        throwayguestman 10y ago
        I do understand, but "the trust you need to put to use the code" is what we were talking about, no?
dozzie 10y ago
> I control a fleet of servers. I have a saltstack or ansible script. One of the steps in provisioning a new server is to pull library X from github.com. Ansible gives larger and easier to exploit attack vectors than git. And then, with pulling semi-random things from internets you have much bigger problems with your deployment procedure. You should never ever download a git repository with software, instead you should be using package system supplied by your operating system.
- mverwijs 10y ago
  > you should be using package system supplied by your operating system 2005-me vehemently agrees with you.
- amingilani 10y ago
  Package managers allow you to download from git repositories too. He'd suffer from the same attack vector.
  - dozzie 10y ago
    Erm... Which ones?
    - shasheene 10y ago
      I believe Homebrew on macOS uses it for formulae (Ruby scripts to actually download and build the application)
      - dozzie 10y ago
        Well, I don't hear too often about a fleet of servers running MacOS (because this branch of comments started with provisioning in a fleet of servers). Also, from rants I hear about Homebrew and its breaking random libraries on upgrades, I don't think it should be mentioned as it was state-of-the-art or something.
    - deleted 10y ago
      [deleted]
danmaz74 10y ago
> Tomorrow, when preimage SHA-1 attacks are cheap, it will no longer save me. Well, Moore's law is petering out isn't it? :)
- runholm 10y ago
  Computers are not getting better at the rate they used to, but we are still improving both on performance and power. However, the largest change we have seen the last couple of years is the accessibility of computer power. These days an attacker can be concerned mostly by how many CPU/GPU hours he needs to rent from Amazon or equivalent providers to achieve his goal. So the accessibility, convenience, and price of processing power is still improving quite fast.
- officelineback 10y ago
  Moore's law is, but the cost of a given amount of computational ability is still going down quickly.
- sqeaky 10y ago
  Depending on your interpretation. If you go by the relatively useless transistor/fixed price cpu then it is dead, but if you go by more practical measures like instructions per second in whole system/dollar the it is as fast as ever. GPUs are really fast and still advancing.

stonogo 10y ago

Sounds like sentence three is where you got it wrong. You should be pulling your software to a development host, building it after verification, and uploading the deployment package to an artifact repository inside your security perimeter. Sentence three becomes 'pull library X from my artifact server.' There is no way to securely deploy a package directly from the internet. The sooner you understand that, the sooner you'll be able to sleep through needless catastrophes like this hypothetical attack -- or leftpad.js.

amingilani 10y ago
Either way he'd be pulling from Github.com at some point, whether in the build environment or production. He won't ever know that the repository was compromised. Besides, some people use Heroku simply to deploy their rails or node apps, and they don't have an artefacts server.
Perseids 10y ago
> There is no way to securely deploy a package directly from the internet. Fetching a file from the internet and verifying it against a hash or signature is the only way to securely deploy a package from the internet. This is exactly one of the use cases theses cryptographic primitives are built for. Don't blame the users when they utilize the tools the way they are supposed to be, blame the tools when they fail when doing so. And by the way, if you ever need to run `apt-get upgrade` or `apt-get install` on your production server from a public mirror, then you are guilty of "deploying a package directly from the internet", too. (My apologies and congratulations if don't.)
- raverbashing 10y ago
  apt-get can (and do) check signatures of repos But yeah, you could put an unverified repos to be used
  - lmm 10y ago
    Git has tag signing, surely there's a way to clone a specific tag and check the signature against a specific GPG key fingerprint?
    - heartsucker 10y ago
      git checkout 0.1.0 git tag -v 0.1.0
    - nhaehnle 10y ago
      Tag signatures only cover the mapping from tag name to commit hash. In other words, specifying a manually-verified commit hash is actually more secure. Tag signatures are mostly worthless now from a crypto point of view -- with the caveat that you can still get some value from them if you still trust sha1 to be secure against second-preimage attacks.
  - Perseids 10y ago
    For the argument at hand (Can you deploy anything on a production server from a third party that is only verified cryptographically?) signatures and hashes fulfill the same function (and btw I also wrote "verifying it against a hash or signature" above). More to the point, under the hood GPG signatures only sign a hash of the file in question anyway. Verifying a file via a GPG signature is strictly less secure than verifying it by its hash (assuming you use the same hash function as the signature).

hasenj 10y ago

If you want a specific hash, why pull it from github everytime?

falsedan 10y ago
Because, when provisioning a new server, where else can you get it from?
- dozzie 10y ago
  From a custom package you have built? Did you know that RPMs and DEBs don't grow on magical trees, but are built?
  - throwayguestman 10y ago
    So, the problem still stands, theoretically. Not only do you likely need to populate your host with packages not from your host. But also, your host will also still be connect to a public net, even if only indirectly (e.g. private net), and hence potentially manipulated.
    - dozzie 10y ago
      No, you misunderstood what is actually the problem here. Pulling under deployment some code from random resource from the internets that can go down or get deleted at a whim and you can't easily move to just some other mirror and you don't even control when the thing will be up back, that's the problem. Not the trust you need to put to use the code (this is still there, obviously). And the very same comment applies to third-party package repositories, like PPAs in Ubuntu. Not to mention that with pre-built binary packages your deployment speed and repeatability get significantly better, as you don't need to rebuild the artifacts every single time.
      - throwayguestman 10y ago
        I do understand, but "the trust you need to put to use the code" is what we were talking about, no?

dozzie 10y ago

> I control a fleet of servers. I have a saltstack or ansible script. One of the steps in provisioning a new server is to pull library X from github.com. Ansible gives larger and easier to exploit attack vectors than git. And then, with pulling semi-random things from internets you have much bigger problems with your deployment procedure. You should never ever download a git repository with software, instead you should be using package system supplied by your operating system.

mverwijs 10y ago
> you should be using package system supplied by your operating system 2005-me vehemently agrees with you.
amingilani 10y ago
Package managers allow you to download from git repositories too. He'd suffer from the same attack vector.
- dozzie 10y ago
  Erm... Which ones?
  - shasheene 10y ago
    I believe Homebrew on macOS uses it for formulae (Ruby scripts to actually download and build the application)
    - dozzie 10y ago
      Well, I don't hear too often about a fleet of servers running MacOS (because this branch of comments started with provisioning in a fleet of servers). Also, from rants I hear about Homebrew and its breaking random libraries on upgrades, I don't think it should be mentioned as it was state-of-the-art or something.
  - deleted 10y ago
    [deleted]

danmaz74 10y ago

> Tomorrow, when preimage SHA-1 attacks are cheap, it will no longer save me. Well, Moore's law is petering out isn't it? :)

runholm 10y ago
Computers are not getting better at the rate they used to, but we are still improving both on performance and power. However, the largest change we have seen the last couple of years is the accessibility of computer power. These days an attacker can be concerned mostly by how many CPU/GPU hours he needs to rent from Amazon or equivalent providers to achieve his goal. So the accessibility, convenience, and price of processing power is still improving quite fast.
officelineback 10y ago
Moore's law is, but the cost of a given amount of computational ability is still going down quickly.
sqeaky 10y ago
Depending on your interpretation. If you go by the relatively useless transistor/fixed price cpu then it is dead, but if you go by more practical measures like instructions per second in whole system/dollar the it is as fast as ever. GPUs are really fast and still advancing.