Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Extra security measures for next week's releases

postgresql.org

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Extra security measures for next week's releases

#31

Post by lawnchair_larry »

trotsky wrote: post #25
georgemcbay wrote: post #4

Wouldn't it make somewhat more sense to branch to a private repo without telling the public, make the required changes there, create the packages from that branch, and then later push the changes into the public repo? The way they are doing it now entices hackers who don't know the exploit but happen to have a recent clone of the repo to look for the big hole in hopes of finding it ahead of the fix. Granted, hackers…

Just knowing there is a preauth RCE in the code base buys you very, very little. Statistically speaking there are probably quite a few unexposed flaws right now in any compact, core linux distribution. The fact that no one yet knows what they are is precisely what prevents the exploitation. Security holes are numerous and the ones that have escaped detection generally continue to do so - the rate of co-discovery is v…

> Just knowing there is a preauth RCE in the code base buys you very, very little.

I disagree with that. That information is highly valuable. Auditing is a risky time investment; you may not find anything useful. Audit time is a finite resource and you want to allocate it where there are vulnerabilities that are useful. There is no way to know that ahead of time.

> Security holes are numerous and the ones that have escaped detection generally continue to do so - the rate of co-discovery is very low in the field.

The rate of co-discovery is fairly high once a second party has been tipped off to the general location and nature of a bug. Most competent auditors will spot the same bugs, especially if the second one already got confirmation that it does in fact exist.

Re: Extra security measures for next week's releases

#32

Post by lawnchair_larry »

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.

Re: Extra security measures for next week's releases

#33

Post by roryokane »

shardling wrote: post #30
ibejoeb wrote: post #6

Earlier quoted context omitted.

Yes, folks are already attempting to find exploitable weakness in these projects. We can assume they exist. Just mentioning that one is confirmed doesn't really lend any insight. The surface area is pretty huge on that project. If I had to guess where it is, though, I'd bet it was in a PL module. I'm sure there is quite a bit of activity around finding NativeHelper-like situations.

>Yes, folks are already attempting to find exploitable weakness in these projects. We can assume they exist. Just mentioning that one is confirmed doesn't really lend any insight. You say that now, then one day, you wake up and all the blue-eyed islanders are gone!

(This is a reference to a logic puzzle about islanders who are able to tell whether they have blue eyes due to someone telling the world that someone has blue eyes. Puzzle at http://xkcd.com/blue_eyes.html , solution at http://xkcd.com/solution.html .)

Re: Extra security measures for next week's releases

#34

Post by onedognight »

willvarfar wrote: post #27

I wonder what the worst possible bug might be? A bug in query parameter parsing that would allow SQL injection attacks?

As conjectured above, the worst case is pre authentication remote code execution. i.e. anyone can just connect, send magic packets, and get a shell.

Re: Extra security measures for next week's releases

#35

Post by tptacek »

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.

Unless it's something that compromises query/statement integrity from normal user input; a character set problem, for instance.

Re: Extra security measures for next week's releases

#36

Post by DigitalJack »

martinced wrote: post #22
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…

I like your explanation about layered solutions to security, +1. "Do you trust your chipsets?" Certainly not. I do believe that the recent tiny bytes sequences in any TCP (UDP ?) packet that can lock Intel ethernet cards is actually a backdoor allowing the state to perform DoS at will. I do also believe Huawei and ZTE are state-sponsored espionage companies (I've certainly seen weird things like a keylogger inside a…

just wanted to let you know you got hellbanned for some reason.

Re: Extra security measures for next week's releases

#37

Post by ef4 »

onedognight wrote: post #34
willvarfar wrote: post #27

I wonder what the worst possible bug might be? A bug in query parameter parsing that would allow SQL injection attacks?

As conjectured above, the worst case is pre authentication remote code execution. i.e. anyone can just connect, send magic packets, and get a shell.

While that would be bad, if it required a magic packet it would have limited impact -- lots of postgres databases don't talk to public networks.

Worse would be a vulnerability that you could trigger just by manipulating query parameters. Then almost every postgres-backed website would be vulnerable.

Re: Extra security measures for next week's releases

#38

Post by JonnieCache »

martinced wrote: post #22
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…

I like your explanation about layered solutions to security, +1. "Do you trust your chipsets?" Certainly not. I do believe that the recent tiny bytes sequences in any TCP (UDP ?) packet that can lock Intel ethernet cards is actually a backdoor allowing the state to perform DoS at will. I do also believe Huawei and ZTE are state-sponsored espionage companies (I've certainly seen weird things like a keylogger inside a…

>I've certainly seen weird things like a keylogger inside a 3G Huawei USB device sold I bought in Europe

Don't tease us like that! Spill the beans!

Re: Extra security measures for next week's releases

#39

Post by fulafel »

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.

Re: Extra security measures for next week's releases

#40

Post by lawnchair_larry »

tptacek wrote: post #35
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.

Unless it's something that compromises query/statement integrity from normal user input; a character set problem, for instance.

Yep, there are a few potential ways that could be exceptions, depending on the bug. But let's not kid ourselves, nobody in the real world properly quarantines their DB servers anyway ;)
Post reply on HN