Extra security measures for next week's releases • Hacker News Board

Re: Extra security measures for next week's releases

#41

Post by lawnchair_larry » Fri, Mar 29, 2013, 6:53 PM UTC

fulafel wrote: post #39

lawnchair_larry wrote: post #32

This bug shouldn't be a huge deal because if you are treating your sensitive database server as anything but exploitable from any machine with network access, you've already lost. Even if your DB server is properly restricted, you should still patch quickly, but there is no way that it should be reachable unless you're already heavily compromised.

This is a pretty firewall happy mindset. Some of us don't have any "internal networks" as a matter of principle.

There are varying degrees of "firewall happiness" and reasonable minds can disagree as to how far you go to balance convenience/security, but...you don't do any network segmentation as a matter of principle? Either I don't understand what you are saying, or you need to make a case for the immediate termination of everybody in charge of your network.

Re: Extra security measures for next week's releases

#42

Post by zer01 » Sat, Mar 30, 2013, 1:38 PM UTC

jimrandomh wrote: post #26

What sort of security vulnerability would justify this extra paranoia? The worst case is that it's something which affects the very-common case of postgres servers that only talk to local services, like a unicode or quoting error that made sites which nominally quote their queries correctly vulnerable to SQL injection. That would be as serious as the recent Rails vulnerabilities: drop everything, patch everything eve…

From what I hear this is pre-auth access to the DB, though it's not from the most reliable of sources.

Re: Extra security measures for next week's releases

#43

Post by ffk » Tue, Apr 02, 2013, 12:28 AM UTC

cbr wrote: post #17

ffk wrote: post #16

Earlier quoted context omitted.

Those are some good observations. Most likely they have given the information to Debian security. With something like this, there is a degree of trust that is maintained. The Debian security team has access to other zero-days on a regular basis, so ideally they aren't compromised. It wouldn't surprise me if AB tests were performed on security experts on a regular basis. E.g. two exploits discovered, one sent to half…

two exploits discovered, one sent to half the team, the other sent to the other half That would only work with brazen leaking. If a security team member were selling 0-days to organizations that intended to make extremely limited and careful use of them, it might never become public that exploits were being leaked.

I agree, I suspect the best way to be caught is for the malicious team member to tell someone who turns them in. Most likely it doesn't ever go noticed. Also, it's fortunate that the information received by the security teams typically has a relatively small window of opportunity to perform the exploit.