3 ms·
Can't tell if this is fud or not. For example with node, typically you'd only be exposing port 80, right? So as long as your http server isn't vulnerable you're
by coleifer 8y ago
Can't tell if this is fud or not. For example with node, typically you'd only be exposing port 80, right? So as long as your http server isn't vulnerable you're ok. Or same with Redis, which I hope isn't anywhere near the public internet?
- pas 8y agoAlso popular, high-velocity projects have a lot of CVEs. That doesn't mean much. How fast these images get updated? How widespread these vulnerable images are?
- acdha 8y ago> So as long as your http server isn't vulnerable you're ok … and everything loaded by every dependency under any situation which doesn't require admin access. Your server can be fine but if e.g. you process images you have to follow libjpeg, libpng, zlib, littlecms, etc. Yes, it's a lot better than a full multiuser Unix system where you have to worry about background processes which aren't useful for a dedicated microservice but there's a long history of vulnerabilities in components being combined into successful exploits and it's usually far more expensive to try to analyze those chains than to upgrade. This brings me to: > Or same with Redis, which I hope isn't anywhere near the public internet? That's hopefully true in general but also consider chained attacks: say you're running a web app and I find a way to run code in the app process. That might be limited but if I can poke at Redis enough to run code there I can test whether you were as diligent about sandboxing it. That'll hurt if, say, there was a container exploit which someone delayed patching because they “knew” our app only runs as an unprivileged user.