4 ms·

There's a reason I submitted this PR one year ago. https://github.com/graycoreio/daffodil/pull/625 https://github.com/graycoreio/daffodil/pull/625 Specifically

There's a reason I submitted this PR one year ago. https://github.com/graycoreio/daffodil/pull/625 https://github.com/graycoreio/daffodil/pull/625 Specifically, > Relying on a curl'd bash script downloaded off your server seems inherently vulnerable (though this apparently applies to many vendors in the space apparently). Checksum procedures should be built into your docs, or you should be using a package registry (ala codecov-node).

lloeki 5y ago
curl | bash only highlights in a very obvious way how vulnerable we can be to supply chain attacks, but is fundamentally not really different than downloading and running a setup.exe a foo.dmg or a foo.deb, running npm/pip/gem/bundle install, or ./configure && make && sudo make install. Even when (if, really) people check for hash, do they check that the hash was published and fetched through a second channel? Nope, people run arbitrary code unchecked all the time, so they're just as equivalent. Even git clone can be dangerous. Do you audit all the repo branch names before cloning? Because depending on how your shell prompt shows e.g branch names it could be used to RCE. EDIT: by this I don't mean to excuse curl | bash and such, I just mean to highlight that the issue runs deeper, curl | bash being the unburied part.
- goatinaboat 5y ago
  is fundamentally not really different than downloading and running a setup.exe a foo.dmg or a foo.deb, running npm/pip/gem/bundle install, or ./configure && make && sudo make install. Well, it is, because any .EXE or .MSI or .DMG I download will pass through one or more virus scanners. You can also do this by forcing users through a proxy such as Artifactory that can also do scanning of Linux packages. But it's futile to rely on automated solutions for NPM or PyPI where there is no curation of the repo so anyone can do typosquatting.
  - lloeki 5y ago
    A virus scanner doesn't help about supply chain attacks, where malicious code is often bespoke and looks entirely like original code except for actual humans auditing the code/binary.
    - goatinaboat 5y ago
      It does when the malicious file is discovered and its signature added to the database. Even if it was allowed to run before, subsequent runs can be blocked and the sysadmin notified.

lloeki 5y ago

curl | bash only highlights in a very obvious way how vulnerable we can be to supply chain attacks, but is fundamentally not really different than downloading and running a setup.exe a foo.dmg or a foo.deb, running npm/pip/gem/bundle install, or ./configure && make && sudo make install. Even when (if, really) people check for hash, do they check that the hash was published and fetched through a second channel? Nope, people run arbitrary code unchecked all the time, so they're just as equivalent. Even git clone can be dangerous. Do you audit all the repo branch names before cloning? Because depending on how your shell prompt shows e.g branch names it could be used to RCE. EDIT: by this I don't mean to excuse curl | bash and such, I just mean to highlight that the issue runs deeper, curl | bash being the unburied part.

goatinaboat 5y ago
is fundamentally not really different than downloading and running a setup.exe a foo.dmg or a foo.deb, running npm/pip/gem/bundle install, or ./configure && make && sudo make install. Well, it is, because any .EXE or .MSI or .DMG I download will pass through one or more virus scanners. You can also do this by forcing users through a proxy such as Artifactory that can also do scanning of Linux packages. But it's futile to rely on automated solutions for NPM or PyPI where there is no curation of the repo so anyone can do typosquatting.
- lloeki 5y ago
  A virus scanner doesn't help about supply chain attacks, where malicious code is often bespoke and looks entirely like original code except for actual humans auditing the code/binary.
  - goatinaboat 5y ago
    It does when the malicious file is discovered and its signature added to the database. Even if it was allowed to run before, subsequent runs can be blocked and the sysadmin notified.