211–220 of 275 posts
Earlier quoted context omitted.
And now Google is picking up the definition of footgun(1) from Hacker news! (1) https://i.imgur.com/pHlLFJA.png
I wonder if someone who's not known to Google to like HN would get the same result?
Earlier quoted context omitted.
That's how both Mongo and MySQL, back in the day, became so popular. They had super lax security, making them easy to use for newbie devs, who are frequently scared/easily distracted by security settings. I'm quite convinced the lack of security was by design. Growth hacking and all that. Get everyone onboard and once you have big business going on, you can focus on the minutiae of security, scaling, not losing data.…
does docker get money, though? anyone with just a bit of common sense has their own docker hub mirror and I don't know how else they earn money...
The development strategy did work, though.
Earlier quoted context omitted.
> Yes, and the fact that docker seems to have persisted with the current state is the topic of discussion. It's clearly written in the docs: To expose a container’s internal port, an operator can start the container with the -P or -p flag. The exposed port is accessible on the host and the ports are available to any client that can reach the host. (from https://docs.docker.com/engine/reference/run/#expose-incomin...…
I don't think that's clear at all. If I set "bind_ip = *" in some application then it's also "available to any client that can reach the host", but the firewall is in front of that. I certainly wouldn't expect an application to frob with my firewall. And as I understand it, this is very much an unintentional side-effect of ufw and Docker interacting – it's not Docker's the intention at all to override any iptable rul…
I get that Docker is often run by devs on their laptops, but this is bad behavior. The simplest solution I've seen so-far is Docker should only automatically set these firewall rules on devices that only have RFC1918 IPs. That would still keep things simple for devs on laptops, but would prevent firewall override on servers.
Earlier quoted context omitted.
It’s exactly the same for redis, which means if used for jobs, you can insert arbitrary code.
All my async job code lives in a codebase and redis merely contains the payload and some ids. What system, framework or stack are you using that stores the code of the job in the database? I'm curious, because I can imagine it solves some issues, e.g. deploying new code while allowing old code to finish running and scheduled jobs.
- run jobs that aren’t supposed to run (removing an account for example, is that’s scheduled after a 2 week grace period) maybe an export or import job. Can be anything of course
- if your job runner allows scripts, or arbitrary class methods, you can do whatever you want
- you can remove jobs if you feel like it
- if you can escape redis because of whatever exploit, you now have access to the internal network
In general I use sidekiq, but resque and inspired implementations generally work on simply calling perform(), so any class with such a method can be called, depending on the typesystem.
The biggest two issues are the ability to perform any defined task, and the larger attack surface of an exposed redis server
Earlier quoted context omitted.
All software is fundamentally helping deal with abstractions as this.
Build systems in general can be ok, or even elegant and fun. Autoconf is just really terrible.
Sendmail is another great example of this phenomenon.
Earlier quoted context omitted.
Your screenshot shows an earlier date (25-Jun-2018) next to the definition.
Yes it links to this comment: https://news.ycombinator.com/item?id=17393292#:~:text=Genera... . The funny thing is there are definitions for it in wikionary and urbandictionary yet it is picking the HN one.
Earlier quoted context omitted.
Clearly it was not fine, but in fact leaky, and depending only on perimeter security was (and is) flawed. See https://collaboration.opengroup.org/jericho/commandments_v1....
There was no perimeter security here. The attacker did not first enter a private network and then pivot to MongoDB; he dialed MongoDB right from the internet. Had Mongo been un-authenticated on a private network it still might have been owned, but the bar would have been a lot higher. Side note: everything that’s ever existed is “flawed,” it’s a weird word to use in the context of something you want to discredit, bec…
...yet MongoDB's (default) configuration assumes there is. That's the big problem with perimeter security: applications offloading their security responsibility to other, possibly imaginary, parts of the system.
Earlier quoted context omitted.
> I don't know why this is being downvoted. The core message ("using auth on MongoDB would have prevented this, it's always a good idea to add password auth just in case") is perfectly reasonable; we can all learn from this, and it's perfectly fine to point out such things. But the way it was phrased was absolutely not okay. People make mistakes all the time and they are not "incompetent". This is the classic "I am v…
Having unauthenticated private services on directly-internet-connected hosts, regardless of the state of the host based firewall, is a mistake that a competent sysadmin does not make. (Then again, so is running MongoDB.) It's not an insult to call someone incompetent.
Yes it is, especially when based on a single data point.