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

21–30 of 43 posts

Re: Extra security measures for next week's releases

#21

Post by zalew »

mixedbit wrote: post #19
dan_manges wrote: post #8

Earlier quoted context omitted.

Knowing that there is a vulnerability might motivate them to look for it, but given the size of the software, I doubt they'll be able to find it without knowing more.

The knowledge may also motivate them to prepare for attacks to be executed once the vulnerability is public but most instances do not have it patched. Scan the Internet for PG backed applications, identify high profile ones, prepare automatic scripts, etc.

> Scan the Internet for PG backed applications, identify high profile ones, prepare automatic scripts, etc.

it rather works like:

- take exploit

- spread it over the whole internet and calls home where it sticks

Re: Extra security measures for next week's releases

#22

Post by martinced »

ffk wrote: post #16
sophacles wrote: post #3

This is an interesting tradeoff between responsible security and open source transparentness that the Postgres team is facing. I personally think this is a good way to handle a situation with a serious bug, but there are some questions it raises... Is Postgres working with downstream teams to have everything in place to do a coordinated security release? For instance, are they working with the likes of Debian's secur…

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 3G Huawei USB device sold I bought in Europe).

But I do believe that even if I'm, say, a Debian or OpenBSD dev working on OpenSSL it's amazingly complicated for the chipset to modify source code and be able to make to the DVCS unnoticed. I also think that as long as the source code isn't corrupted there are ways to create non-backdoored builds.

It's the same thing with program provers that can verify that certain piece of code are guaranteed to be free of buffer overrun/overflow: what proves that the compiler itself hasn't been tampered with? But still... With DVCSes and many eyeballs I'm not that much concerned about the compilers typically used nowadays to be tampered with.

Re: Extra security measures for next week's releases

#23

Post by selenamarie »

We've now posted a general announcement about the availability of packages on April 4, 2013: http://www.postgresql.org/message-id/CAN1EF+x0dmwMFuJGWuXMiR... and http://www.postgresql.org/about/news/1454/

As stated in the announcement and Tom's email to -hackers, the reasons for advanced notifications are as follows:

* People watching for vulnerabilities and contributors are going to notice that we've stopped automatic updates -- it's better for our project to just tell them all why

* Upgrading relational databases is often not trivial -- we want to give our users time to schedule an upgrade rather than just dropping an important update suddenly

Re: Extra security measures for next week's releases

#24

Post by sophacles »

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…

Tinfoil hat time... Does anyone ever reverse gcc binaries to verify? I mean it seems that many eyeballs on the source code actually provides a negative effect to people examining the binaries, because why do it when the source is right there?

Re: Extra security measures for next week's releases

#25

Post by trotsky »

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 very low in the field.

Warning ahead of time is thus often very useful - it allows the infrastructure to prepare to make the changes quickly. This is the same reason that folks like Microsoft consolidate most patches into standardized cycles.

Re: Extra security measures for next week's releases

#26

Post by jimrandomh »

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 everywhere, or definitely be rooted.

Be ready to patch as soon as it's out; this could be a big deal.

Re: Extra security measures for next week's releases

#29

Post by mikeash »

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…

The Intel ethernet controller lockup seems like a really bad candidate for an intentional backdoor. It's way too easy to trigger by accident (a single byte with the right value in the right place!) and yet way too hard to trigger intentionally (a slightly different value immunizes the controller).

Surely an actual backdoor would require something a little harder to stumble over by accident, and wouldn't have a trivial disable code.

Re: Extra security measures for next week's releases

#30

Post by shardling »

ibejoeb wrote: post #6
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…

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!

Post reply on HN