5 ms·

You also cannot publish little known pre-auth remote code execution vulnerabilities for your web-framework without first publishing a mitigation patch that does

by moe 14y ago

You also cannot publish little known pre-auth remote code execution vulnerabilities for your web-framework without first publishing a mitigation patch that doesn't paint a BIG FAT RED ARROW onto the attack vector. You also cannot leave 6 years of vulnerable Rails-versions up on rubygems.org without even backporting your patch (yes, they're still up there now). It makes no sense to blame the users of a web-framework, most of which are not security experts, for not responding instantly with the perfectly correct procedure to an event of this magnitude. Put the blame where it belongs, on the idiots who "handled" the issue by releasing a "recipe to exploit"-Advisory. The same idiots who ramble about "not breaking old apps" when asked why the vulnerable gems are still up on rubygems.org and continue to be quietly installed by any Gemfile referencing them...

danielweber 14y ago
As a fan of responsible disclosure, the sad state of the universe is that telling people "upgrade to X now" on an open-source project makes it very easy for anyone to diff to find out what the fix is, which makes it very easy for people to figure out how to exploit it.
- moe 14y ago
  No. A thousand times. A bit more creativity should be allowed when handling a vulnerability of this magnitude. For example, publish a patch that escapes all input in curious ways, presumably to prevent SQL injection. Pad it, obfuscate the actual fix with code-noise, make it annoying to read. Then release it as some handwavy, semi-plausible "follow-up" to the previous SQL-injection, urging everyone to upgrade in small caps. Yes, a handful of blackhats will see through the bluff. However, it will likely be the exact same blackhats that already had discovered the issue after the initial SQL injection advisory. This would have given the Rails-community a head-start, rather than unleashing every script-kiddy on the planet at once.
  - m0nastic 14y ago
    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".
  - tptacek 14y ago
    I was actually pretty upset because I thought that might have been what the Rails team was trying to do --- to come up with an occlusive patch, like you're advocating. Because that plan was. not. going. to. work. When multiple teams flag the same RCE on the same day, the only reasonable conclusion to come to is that the cat is out of the bag. What needed to happen is what happened: a patch and a series of workarounds were produced as soon as possible. Nobody got to choreograph this one. The control you think the Rails team had over this, they did not have.
  - bradleyland 14y ago
    I was actually pretty pissed that it wasn't explicitly labeled as a "remote code execution" vulnerability in the CVE post title. This is open source, you don't get to hide. The code is there. Trying to be clever about releasing a patch isn't going to help, because every patch gets looked at by a large community of security people. Some of those people are the good guys, but some are the bad guys. Nothing about this situation was good, but hiding it would have only made it worse. When you're serving shit sandwiches for lunch, it's best to let everyone know that's what's on the menu. End of story.
  - tedunangst 14y ago
    This is terrible. The OpenBSD/SSH team tried this once, with the channel bug. They released the privsep version of ssh which didn't fix but mitigated the bug, and told everybody there was a critical bug and you really, really wanted to upgrade. What happened next? Everybody from Alan Cox on down started complaining about how they weren't going to dance to somebody else's tune and they were going to wait to see the real fix, thank you very much.
    - moe 14y ago
      Now that's an interesting reference! I actually remember this incident (albeit blurredly, hell, was that really 10 years ago...). I dug up a few snippets[1] and I think the main sources of the animosities back then were certain regressions caused by privsep (not a hassle-free change) and a bit of ego-clashing (Alan Cox, Theo). Your summary of the events may be about right, but is "not wanting to dance to someone else's tune" really a good argument against an attempt at responsible disclosure? [1] http://www.baylisa.org/pipermail/baylisa/2002-June.txt http://www.baylisa.org/pipermail/baylisa/2002-June.txt (at the bottom) [1] http://seclists.org/bugtraq/2002/Jun/300 http://seclists.org/bugtraq/2002/Jun/300
tptacek 14y ago
I sympathise with you but (a) none of this matters in context; you still have to fix immediately or pull the plug and (b) you are deluding yourself if you think a flaw that 5 teams found independently the day the last SQLI advisory was released wasn't going to be in Metasploit within 7 days. This bug was too damn blatant. I don't know why people weren't taking a hard look at the params processing code path in Rails for 6 years, but they clearly weren't. The SQLI bug from last week pointed people at that code, it got its first real shake, and that's all there is to say about it.

by moe 14y ago

danielweber 14y ago

As a fan of responsible disclosure, the sad state of the universe is that telling people "upgrade to X now" on an open-source project makes it very easy for anyone to diff to find out what the fix is, which makes it very easy for people to figure out how to exploit it.

moe 14y ago
No. A thousand times. A bit more creativity should be allowed when handling a vulnerability of this magnitude. For example, publish a patch that escapes all input in curious ways, presumably to prevent SQL injection. Pad it, obfuscate the actual fix with code-noise, make it annoying to read. Then release it as some handwavy, semi-plausible "follow-up" to the previous SQL-injection, urging everyone to upgrade in small caps. Yes, a handful of blackhats will see through the bluff. However, it will likely be the exact same blackhats that already had discovered the issue after the initial SQL injection advisory. This would have given the Rails-community a head-start, rather than unleashing every script-kiddy on the planet at once.
- m0nastic 14y ago
  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".
- tptacek 14y ago
  I was actually pretty upset because I thought that might have been what the Rails team was trying to do --- to come up with an occlusive patch, like you're advocating. Because that plan was. not. going. to. work. When multiple teams flag the same RCE on the same day, the only reasonable conclusion to come to is that the cat is out of the bag. What needed to happen is what happened: a patch and a series of workarounds were produced as soon as possible. Nobody got to choreograph this one. The control you think the Rails team had over this, they did not have.
- bradleyland 14y ago
  I was actually pretty pissed that it wasn't explicitly labeled as a "remote code execution" vulnerability in the CVE post title. This is open source, you don't get to hide. The code is there. Trying to be clever about releasing a patch isn't going to help, because every patch gets looked at by a large community of security people. Some of those people are the good guys, but some are the bad guys. Nothing about this situation was good, but hiding it would have only made it worse. When you're serving shit sandwiches for lunch, it's best to let everyone know that's what's on the menu. End of story.
- tedunangst 14y ago
  This is terrible. The OpenBSD/SSH team tried this once, with the channel bug. They released the privsep version of ssh which didn't fix but mitigated the bug, and told everybody there was a critical bug and you really, really wanted to upgrade. What happened next? Everybody from Alan Cox on down started complaining about how they weren't going to dance to somebody else's tune and they were going to wait to see the real fix, thank you very much.
  - moe 14y ago
    Now that's an interesting reference! I actually remember this incident (albeit blurredly, hell, was that really 10 years ago...). I dug up a few snippets[1] and I think the main sources of the animosities back then were certain regressions caused by privsep (not a hassle-free change) and a bit of ego-clashing (Alan Cox, Theo). Your summary of the events may be about right, but is "not wanting to dance to someone else's tune" really a good argument against an attempt at responsible disclosure? [1] http://www.baylisa.org/pipermail/baylisa/2002-June.txt http://www.baylisa.org/pipermail/baylisa/2002-June.txt (at the bottom) [1] http://seclists.org/bugtraq/2002/Jun/300 http://seclists.org/bugtraq/2002/Jun/300

tptacek 14y ago

I sympathise with you but (a) none of this matters in context; you still have to fix immediately or pull the plug and (b) you are deluding yourself if you think a flaw that 5 teams found independently the day the last SQLI advisory was released wasn't going to be in Metasploit within 7 days. This bug was too damn blatant. I don't know why people weren't taking a hard look at the params processing code path in Rails for 6 years, but they clearly weren't. The SQLI bug from last week pointed people at that code, it got its first real shake, and that's all there is to say about it.