3 ms·

So you're advocating releasing a "decoy" patch that's intentionally obtuse and doesn't actually fix the issue? And then downplaying the severity by not encoura

So you're advocating releasing a "decoy" patch that's intentionally obtuse and doesn't actually fix the issue? And then downplaying the severity by not encouraging developers to take the follow-up patch seriously? That's a flat out terrible idea.

moe 14y ago
No. I was advocating to release a patch that fixes the issue in an obfuscated, non-obvious way. And labeling it as a boring-yet-important follow-up to the previous SQL-injection vulnerability, rather than yelling "LOOK, REMOTE CODE INJECTION HERE -->.<-- !!" on all available news-channels.
- m0nastic 14y ago
  Would you invest time in a framework where the developers knowingly lie about security vulnerabilities and provide fixes that are intentionally complicated? That seems like something that would ruin any future credibility of the project. No further security vulnerabilities could be trusted as being accurate (and any further patches would just be begging for additional scrutiny).
  - moe 14y ago
    That "concern" is absurd. You're making no sense.
    - m0nastic 14y ago
      If a Linux distro released a kernel patch for a super-critical security vulnerability that lied about its nature, AND downplayed its importance, users would go apeshit (justifiably).
      - moe 14y ago
        You're still making no sense. Various large projects, including the kernel, have seen silent security patches (yes, even by Linus himself). Also there is no "downplaying" in declaring any kind of problem as a remote SQL injection vulnerability. That is still obviously urgent enough for everyone to patch immediately. Yet it doesn't attract blackhats in the same way as blarting "remote code injection".
        m0nastic 14y ago
        Mis-labeling a Remote Code Execution vulnerability as SQL-I is absolutely downplaying the severity. SQL-I is a bad finding, RCE is tantamount to the worst thing you could possibly find in an application. There were people on this very site who were commenting about whether they should concern themselves with this patch (initially because people erroneously attributed the vuln to SQL-I, and then later because they "weren't using XML anyway") Those kinds of things happen when you don't clearly describe what a vulnerability is, and when you try to mask how big of a deal something is. This was a huge vulnerability. It was critically important that everyone running a Rails app fix it immediately. Shouting that from the rooftops was absolutely the right approach. Cloak and Dagger bullshit to try and hide that is unequivocally a bad idea.
        tptacek 14y ago
        In fairness, while I'm specifically not a fan of that Phusion post, it was referring to a bug that wasn't an RCE.
        m0nastic 14y ago
        Right, the Phusion post was referring to the previous bug though, right? I disagree with Moe that labeling the latest bug as an SQL-I instead of RCE is a good strategy to ward off blackhats.
        moe 14y ago
        Well, the votes are strongly in your favor, but I remain unconvinced - accepting that I'm in the minority here. For me this very article (bitcoin exchange being hacked) demonstrates that despite the harsh wording, the advisory didn't reach everyone in time. Not even those who should really care (like bitcoin exchanges). I still think the explicit disclosure did more harm than good, by drawing maximum attention from the blackhat-community without really improving the reach amongst the oblivious. I still think a "staged" disclosure might have worked better, even at the risk of the timeline being short-circuited by a malicious party spilling the beans early. However, there's little point bemoaning this particular baby or bathwater much more now. I'm more interested in the steps that the Rails-team will be taking to lessen the blow by future security incidents. As I've said in another thread I'd be in favor of an optional (opt-in) kill-switch, to be triggered only in drastic cases like this one. Perhaps that is a point where we can agree again - otherwise we'll have to part in disagreement. :)
- danielweber 14y ago
  How much time do you think that would have bought? At least a few minutes, but definitely not days. And at what cost would it be? I'm all in favor of giving people more time to upgrade, but this issue was very unusual. Multiple groups were all finding it at the same time and who knows when the first "full disclosure is always the right answer" group would have started singing? Like it or not, full-disclosure people exist in the world, and responsible-disclosure people need to be aware of their existence. If just one person/group had found this, RoR could have done a better "get ready to upgrade next Tuesday at 6am" followed by a "here is the patch, details to follow tomorrow" on Tuesday at 6am.

moe 14y ago

No. I was advocating to release a patch that fixes the issue in an obfuscated, non-obvious way. And labeling it as a boring-yet-important follow-up to the previous SQL-injection vulnerability, rather than yelling "LOOK, REMOTE CODE INJECTION HERE -->.<-- !!" on all available news-channels.

m0nastic 14y ago
Would you invest time in a framework where the developers knowingly lie about security vulnerabilities and provide fixes that are intentionally complicated? That seems like something that would ruin any future credibility of the project. No further security vulnerabilities could be trusted as being accurate (and any further patches would just be begging for additional scrutiny).
- moe 14y ago
  That "concern" is absurd. You're making no sense.
  - m0nastic 14y ago
    If a Linux distro released a kernel patch for a super-critical security vulnerability that lied about its nature, AND downplayed its importance, users would go apeshit (justifiably).
    - moe 14y ago
      You're still making no sense. Various large projects, including the kernel, have seen silent security patches (yes, even by Linus himself). Also there is no "downplaying" in declaring any kind of problem as a remote SQL injection vulnerability. That is still obviously urgent enough for everyone to patch immediately. Yet it doesn't attract blackhats in the same way as blarting "remote code injection".
      - m0nastic 14y ago
        Mis-labeling a Remote Code Execution vulnerability as SQL-I is absolutely downplaying the severity. SQL-I is a bad finding, RCE is tantamount to the worst thing you could possibly find in an application. There were people on this very site who were commenting about whether they should concern themselves with this patch (initially because people erroneously attributed the vuln to SQL-I, and then later because they "weren't using XML anyway") Those kinds of things happen when you don't clearly describe what a vulnerability is, and when you try to mask how big of a deal something is. This was a huge vulnerability. It was critically important that everyone running a Rails app fix it immediately. Shouting that from the rooftops was absolutely the right approach. Cloak and Dagger bullshit to try and hide that is unequivocally a bad idea.
        tptacek 14y ago
        In fairness, while I'm specifically not a fan of that Phusion post, it was referring to a bug that wasn't an RCE.
        m0nastic 14y ago
        Right, the Phusion post was referring to the previous bug though, right? I disagree with Moe that labeling the latest bug as an SQL-I instead of RCE is a good strategy to ward off blackhats.
        moe 14y ago
        Well, the votes are strongly in your favor, but I remain unconvinced - accepting that I'm in the minority here. For me this very article (bitcoin exchange being hacked) demonstrates that despite the harsh wording, the advisory didn't reach everyone in time. Not even those who should really care (like bitcoin exchanges). I still think the explicit disclosure did more harm than good, by drawing maximum attention from the blackhat-community without really improving the reach amongst the oblivious. I still think a "staged" disclosure might have worked better, even at the risk of the timeline being short-circuited by a malicious party spilling the beans early. However, there's little point bemoaning this particular baby or bathwater much more now. I'm more interested in the steps that the Rails-team will be taking to lessen the blow by future security incidents. As I've said in another thread I'd be in favor of an optional (opt-in) kill-switch, to be triggered only in drastic cases like this one. Perhaps that is a point where we can agree again - otherwise we'll have to part in disagreement. :)
danielweber 14y ago
How much time do you think that would have bought? At least a few minutes, but definitely not days. And at what cost would it be? I'm all in favor of giving people more time to upgrade, but this issue was very unusual. Multiple groups were all finding it at the same time and who knows when the first "full disclosure is always the right answer" group would have started singing? Like it or not, full-disclosure people exist in the world, and responsible-disclosure people need to be aware of their existence. If just one person/group had found this, RoR could have done a better "get ready to upgrade next Tuesday at 6am" followed by a "here is the patch, details to follow tomorrow" on Tuesday at 6am.