4 ms·

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

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 security team (for example) to not only make the direct source pullable, but also have releases available to as many users as possible in the platform preferred formats? If they are, how do they do keep this under wraps? It seems like the kind of thing that would require a fairly wide "pre-disclosure", and managing trust in a large network gets hard.

danielweber 14y ago
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.
- sounds 14y ago
  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.
ffk 14y ago
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 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/hacked-hardware-has-been-sold-in-the-u-s/ 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.
- cbr 14y ago
  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.
  - ffk 14y ago
    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.
- martinced 14y ago
  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.
  - sophacles 14y ago
    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?

danielweber 14y ago

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.

sounds 14y ago
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.

ffk 14y ago

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 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/hacked-hardware-has-been-sold-in-the-u-s/ 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.

cbr 14y ago
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.
- ffk 14y ago
  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.
martinced 14y ago
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.
- sophacles 14y ago
  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?