5 ms·

If Equifax were running a vulnerable version of Apache Struts on CoreOS the the hack would have still happened. That the CoreOS CEO has chosen to use the Equif

If Equifax were running a vulnerable version of Apache Struts on CoreOS the the hack would have still happened. That the CoreOS CEO has chosen to use the Equifax hack as a marketing opportunity is equally distasteful and disingenuous. Also invoking the founding fathers, the Bill of Rights and the great Dr Martin Luther King in the as part of that marketing pitch is the height of bombast and absurdity. This blog post could have been written by Gavin Belson.

deleted 9y ago
[deleted]
sheeshkebab 9y ago
It depends on the base docker image this struts2 web app would run on, and whether it would allow running OS commands involved into the hack, but yeah, coreos/tectonic is not exactly known for any security features that would have helped with this.
StefanKarpinski 9y ago
One of the features of their stack is live single-click or even auto-update of you technology stack while your application keeps running. While that doesn't necessarily mean that you will keep your stack up-to-date, it makes patching security issues considerably easier and less painful, which means it's far less likely that you will be running a known-vulnerable version. So it's not entirely BS, even though why CoreOS helps security isn't spelled out here. I happen to have watched a talk where Alex Polvi did spell this out just last night, which is the only reason I know this. But yes, the rhetoric is a bit heavy-handed.
- oso2k 9y ago
  This is built-in functionality of Kubernetes (& OpenShift) called Rolling Update [0]/Rolling Deployments [1] and Image Triggers [2]. [0] https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/ https://kubernetes.io/docs/tasks/run-application/rolling-upd... [1] https://docs.openshift.com/container-platform/3.6/dev_guide/deployments/deployment_strategies.html#rolling-strategy https://docs.openshift.com/container-platform/3.6/dev_guide/... [2] https://docs.openshift.com/container-platform/3.6/dev_guide/builds/triggering_builds.html#image-change-triggers https://docs.openshift.com/container-platform/3.6/dev_guide/...
SEJeff 9y ago
CoreOS's clair[1] will automatically reject (or alert) on new deployments of containers with known CVEs. So at a minimum, it could have let the administrators know they were running vulnerable images and fix the issue before the hack occurred. [1] https://github.com/coreos/clair https://github.com/coreos/clair

deleted 9y ago

[deleted]

sheeshkebab 9y ago

It depends on the base docker image this struts2 web app would run on, and whether it would allow running OS commands involved into the hack, but yeah, coreos/tectonic is not exactly known for any security features that would have helped with this.

StefanKarpinski 9y ago

One of the features of their stack is live single-click or even auto-update of you technology stack while your application keeps running. While that doesn't necessarily mean that you will keep your stack up-to-date, it makes patching security issues considerably easier and less painful, which means it's far less likely that you will be running a known-vulnerable version. So it's not entirely BS, even though why CoreOS helps security isn't spelled out here. I happen to have watched a talk where Alex Polvi did spell this out just last night, which is the only reason I know this. But yes, the rhetoric is a bit heavy-handed.

oso2k 9y ago
This is built-in functionality of Kubernetes (& OpenShift) called Rolling Update [0]/Rolling Deployments [1] and Image Triggers [2]. [0] https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/ https://kubernetes.io/docs/tasks/run-application/rolling-upd... [1] https://docs.openshift.com/container-platform/3.6/dev_guide/deployments/deployment_strategies.html#rolling-strategy https://docs.openshift.com/container-platform/3.6/dev_guide/... [2] https://docs.openshift.com/container-platform/3.6/dev_guide/builds/triggering_builds.html#image-change-triggers https://docs.openshift.com/container-platform/3.6/dev_guide/...

SEJeff 9y ago

CoreOS's clair[1] will automatically reject (or alert) on new deployments of containers with known CVEs. So at a minimum, it could have let the administrators know they were running vulnerable images and fix the issue before the hack occurred. [1] https://github.com/coreos/clair https://github.com/coreos/clair