In relation to the criticism about Heroku's early access: "Heroku was given access to updated source code which patched the vulnerability at the same time as other packagers. Because Heroku was especially vulnerable, the PostgreSQL Core Team worked with them both to secure their infrastructure and to use their deployment as a test-bed for the security patches, in order to verify that the security update did not break any application functionality. Heroku has a history both of working closely with community developers, and of testing experimental features in their PostgreSQL service."
> Any system that allows unrestricted access to the PostgreSQL network port, such as users running PostgreSQL on a public cloud, is especially vulnerable.
Heroku allows unauthenticated access to the Postres port to anyone on the Internet? I guess that makes development a lot faster for users... nobody has to think about the implications of secured ports if you just punt on securing them.
I believe they mean unrestricted as in not behind a firewall.
Heroku still requires authentication, but doesn't filter access by ip. If someone wanted to they could port-scan all of Heroku's (and really Amazon) internal network and find quite a few postgresql servers listening on network ports.
> Heroku still requires authentication, but doesn't filter access by ip.
Which means unauthenticated access to the postgres port as I said in my post. I didn't say "unauthenticated access to postgres" which would be plainly ridiculous.
> An more detailed writeup, but hardly satisfying. Like most of Heroku's technical choices made in the name of "simplicity" and "robustness."
> But I guess I should accept that Heroku will never be a technically impressive PaaS provider. Just the one I hear about the most.
Many people care about robustness the most, bar none. We can't have everything all the time, just as Linux doesn't implement a ton of stuff seen on old mainframe kernels. Many things have not caught up with Tandem Computers, either -- re-inventing all that kind of stuff, even if only to recast it in modern settings, is time consuming, especially if one wants to keep the 'weird factor' low, and mitigate lock-in. There's a non-zero risk of things going horrifically wrong, too.
The best I can do is let folks appreciate the difficulty, but that's really in part a coded way of saying "not a three-line fix, so if this is a deal breaker, move on." If you thought it was also interesting, then all my objectives for that writing are met.
So, sorry in advance if a lot of Heroku things aren't very impressive, and I try to make things a tiny bit better day by day. Maybe one day you'll be impressed.
>Who discovered the vulnerability?
>Mitsumasa Kondo and Kyotaro Horiguchi of NTT Open Source Software Center while conducting a security audit.
I'm not surprised. Some years ago I worked for a company that had NTT as a customer, and they were easily an order of magnitude more thorough and careful than anyone else. We used to joke that they knew our product better than we did.
10 comments
[ 3.5 ms ] story [ 22.9 ms ] threadHeroku allows unauthenticated access to the Postres port to anyone on the Internet? I guess that makes development a lot faster for users... nobody has to think about the implications of secured ports if you just punt on securing them.
Heroku still requires authentication, but doesn't filter access by ip. If someone wanted to they could port-scan all of Heroku's (and really Amazon) internal network and find quite a few postgresql servers listening on network ports.
That's what this is intended to prevent.
Which means unauthenticated access to the postgres port as I said in my post. I didn't say "unauthenticated access to postgres" which would be plainly ridiculous.
But I guess I should accept that Heroku will never be a technically impressive PaaS provider. Just the one I hear about the most.
> But I guess I should accept that Heroku will never be a technically impressive PaaS provider. Just the one I hear about the most.
Many people care about robustness the most, bar none. We can't have everything all the time, just as Linux doesn't implement a ton of stuff seen on old mainframe kernels. Many things have not caught up with Tandem Computers, either -- re-inventing all that kind of stuff, even if only to recast it in modern settings, is time consuming, especially if one wants to keep the 'weird factor' low, and mitigate lock-in. There's a non-zero risk of things going horrifically wrong, too.
The best I can do is let folks appreciate the difficulty, but that's really in part a coded way of saying "not a three-line fix, so if this is a deal breaker, move on." If you thought it was also interesting, then all my objectives for that writing are met.
So, sorry in advance if a lot of Heroku things aren't very impressive, and I try to make things a tiny bit better day by day. Maybe one day you'll be impressed.
I'm not surprised. Some years ago I worked for a company that had NTT as a customer, and they were easily an order of magnitude more thorough and careful than anyone else. We used to joke that they knew our product better than we did.