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

Re: Extra security measures for next week's releases

#11

Post by Cyranix » Thu, Mar 28, 2013, 8:40 PM UTC

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…

The repo is only being hidden for a week ("until Thursday morning"), which to me implies that the fix is localized and/or well understood. That's a pretty small window of time, so I'm not sure that it will provide any additional impetus for exploit developers.

Re: Extra security measures for next week's releases

#12

Post by rosser » Thu, Mar 28, 2013, 8:49 PM UTC

jfim wrote: post #10

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.

You'd be surprised; on Windows, at least, there are people who reverse engineer the security patches from Microsoft in order to determine the initial vulnerability[1]. [1] http://www.phreedom.org/presentations/reverse-engineering-an... Edit: Misinterpreted your post. You're right, it's unlikely that they'll guess where it is until a patch comes out.

Because there are enough people running Windows who haven't applied the patch that figuring out how to exploit it is a worthwhile undertaking.

Then again, IME of many years as a PostgreSQL DBA, the vast, overwhelming majority of postgres shops aren't running anywhere near the latest release, so depending on how far back this vulnerability goes, there could be a very large number of exploitable targets...

Re: Extra security measures for next week's releases

#13

Post by aporl » Thu, Mar 28, 2013, 8:50 PM UTC

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, this is pretty absurd.

Re: Extra security measures for next week's releases

#14

Post by danielweber » Thu, Mar 28, 2013, 8:50 PM UTC

How far back does Postgres maintain old versions? Will, say, Postgres 8 be updated with this fix (assuming the problem is in Postgres 8)?

EDIT: Here is the answer: http://www.postgresql.org/support/versioning/

8.0 was EOL'd in 2010, but 8.4 will go through July 2014.

Re: Extra security measures for next week's releases

#15

Post by danielweber » Thu, Mar 28, 2013, 8:56 PM UTC

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…

A lot of the people they need help from don't need to know the specifics.

They can tell Debian what is basically in this mail, and Debian can be ready to accept a new package.

Re: Extra security measures for next week's releases

#16

Post by ffk » Thu, Mar 28, 2013, 9:09 PM UTC

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 the team, the other sent to the other half. After a log(n) number of iterations, potential leaks are exposed.

Diving further though, at what level do you say you trust the system though? Do you trust your compilers to not inject malicious code? (see http://c2.com/cgi/wiki?TheKenThompsonHack) Do you trust peripheral devices? It's very easy to install a physical key logger into a system. Do you trust your chipsets? Compromised chipsets exist and can be used against you. (http://blogs.scientificamerican.com/observations/2011/07/11/...)

It's a tough situation to deal with. This is part of the reason layered security solutions are typically employed. Even if one system has a zero-day, ideally multiple layers should increase the overall complexity of triggering it. One of those layers are security teams and blackout periods where information is not released to the general public, even if they aren't always effective.

Re: Extra security measures for next week's releases

#17

Post by cbr » Thu, Mar 28, 2013, 9:28 PM UTC

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…

    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.

Re: Extra security measures for next week's releases

#18

Post by brokenparser » Thu, Mar 28, 2013, 9:40 PM UTC

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.

It has to be something severe for this scenario to come into play. A broken procedure can only be exploited if such a procedure exists and can be invoked as the definer. This model is well understood by all, to the point a vulnerable PL may not be a critical issue for most users.

Given the precautions that have been implemented, my bets are on authentication. This would mostly affect TCP/IP enabled hosts, which is fortunately not a default configuration (tested on Ubuntu).

Re: Extra security measures for next week's releases

#19

Post by mixedbit » Thu, Mar 28, 2013, 9:47 PM UTC

dan_manges wrote: post #8

thomasvendetta wrote: post #5

Earlier quoted context omitted.

And now the bad guys know there is a very serious vulnerability, somewhere.

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.

Re: Extra security measures for next week's releases

#20

Post by sounds » Thu, Mar 28, 2013, 10:09 PM UTC

danielweber wrote: post #15

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…

A lot of the people they need help from don't need to know the specifics. They can tell Debian what is basically in this mail, and Debian can be ready to accept a new package.

I agree.

As long as the debian infrastructure is fully automated (it is), the actual time delay from pgsql's announcement to it hitting debian servers would be only an hour or so.