5 ms·
Security is not that much improved to be true. Docker is just a fancy chroot, a motivated attacker can escape from it, it remains far less secure than a freebs
by kakwa_ 10y ago
Security is not that much improved to be true.
Docker is just a fancy chroot, a motivated attacker can escape from it, it remains far less secure than a freebsd jail or a solaris zone.
Except maybe some somewhat safer compiled languages (rust, newer versions of C++), and a few interesting tools (like AFL), there was not much improvements in security mechanism in late years.
SELinux is still so annoying that it's commonly the first thing disabled in many install.
A large amount of sysadmins and developers still do a chmod -R 777, not fully understanding what there are doing.
And in the area of micro services, the traditional 3/4 tiers architecture can easily be replaced by a clusterfuck of containers deployed in a flat network where it's impossible to monitor what is speaking with what. And it's much easier to make a mistake like putting a database on the Internet with no authentication whatsoever...
What is more, because of containers, infrastructures tends to be far more diverse than ever: python, node, php, ruby, go, java, each with various version, from various distribution, with various libraries. Each of these environments must be properly monitored, but when you deal with thousands of containers, hundreds of technological stacks, with 3 or 4 versions for each layer, it becomes a nightmare.
In languages that encourage bundling, Java with war webapps for example, I've rarely seen developers properly monitor security issues of what they ship. Too often I've seen only opportunistic updates. And in some extreme cases I've seen products shipping version of libraries 10 or even 15 years old.
Containers being a way to generalize bundling, I don't see it being an improvement in that regard. Quite the contrary in fact.
However, to be completely honest, new tools like chef/puppet/containers and new methodologies like Infrastructure as Code somewhat helped to be less frighten about updates as it reduces the risk/impact of something breaking in the process, no more 'don't touch it, it will break comething'. Even containers can help in that regard, it's easier to do AB testing, avoid downtime or put servers in maintenance with them.
Fundamentally, some things are better, some things are worth, and in the end the security level has not really changed.
And honestly, it's a truly frightening view. Software/Infrastructure security is becoming more and more important as sensitive operations are increasingly done through websites (ex: banking operation), private data is increasingly stored in the "cloud" and an increasing number of devices are now connected.
Security flows are still as numerous as before, but their impact, once exploited, tends to be far greater. If it continues like that, something really bad will happen, exactly what is difficult to predict (massive data leak? major industrial disaster caused by a hack? an election being manipulated?), but it will happen.
- cyberpunk 10y agoThe OS and even the lower level libs are rarely the first target anymore unless there are some nice pre-packed pwns on msploit or whereever; sure -- there are exploitable bugs in such things but even getting to these hosts are hard now we're in the age of CDN's and ELBs and so on.. Also NX, ASLR, nonexec heap, tools like selinux etc etc have made pwning these as 0day a much harder thing. So; the noobs have gone upstack. Why bother trying to break out of an ASLR'd JVM behind a CDN with selinux and etc just to get a shell on a box if your goal is to read a .properties so you can dump the db out? Instead you can probably pull the data one rq at a time with some bad form sanitation or whatever? The latter also means you're targetting code the actual target has written which is more likely to have easy to find issues as no one but the target is looking over it than say, openssl which has rather a few eyes on it.. There's a flipside to config mgt from security tho.. Tools like chef/puppet, while enabling you to maintain a _basic_ level of state actually tend to be great attack surfaces and so overall reduce your sec. How many ops teams out there would notice if you pwned one of their lappys and replaced some puppet handler code before they push it into CI and it gets run across their entire estate? Over-Using config mgt (like using it to orcestrate app deploys) with even mid skilled ops folks generally makes an attackers job much easier than say, rolling out immutable containers.. Most places I've seen without much thought have ended up with superpowerful CI boxes that by owning you get absolutely EVERYTHING and they'll happily give out keys to all the devs while not letting them near prod... >_< If you have a shell account on a CI and the jenkins taskrunner user has access to ssh in anywhere you want to be, then you're just a commit away from having those rights too... Just my $0.02 (edit: actually, if you just have commit rights to any ./script that is running on that jenkins, you can do everything that jenkins can do without even needing a shell... Your jenkins builds the artefacts for your app and ALSO does the deploys? Bet you can get into prod with two lines of nc and push)...
- vacri 10y ago> How many ops teams out there would notice if you pwned oneof their lappys Why are their lappys on the internet? Aren't we discussing online vulnerabilities? After all, if you pwn an admin-credentialled computer, you can do all sorts of damage in any but the most locked-down shop. Puppet has little to do with it per se - it's the privileges an ops laptop will have that matters.