5 ms·

Did I read that right? They reported the bug to Google on August 7th and disclosed it publicly on August 13th? Is this still responsible disclosure if they giv

Did I read that right? They reported the bug to Google on August 7th and disclosed it publicly on August 13th? Is this still responsible disclosure if they give Google basically 6 days to respond and use the original notification date as justification? I'm not learned enough in the practice of responsible disclosure to know if this is common, but I've not seen that before.

deleted 11y ago
[deleted]
jimrandomh 11y ago
It isn't a new bug; what they're reporting is that the patch which was supposed to fix an already-publicly-disclosed bug doesn't fully fix it.
- josh2600 11y ago
  Can you help me understand this? They're complaining about a bug in the patch implementation and the patch implementation did not exist prior to the patch; ergo, if Google didn't patch the code, they wouldn't be able to write the article. Is that not a new bug almost definitionally? Please help me understand if I am incorrect. I understand the underlying issue which was first reported did not get patched properly, but, if someone found a bug in the heartbleed patch today and disclosed it immediately with the original patch date as justification, I would imagine many would be screaming bloody murder.
  - adrianlmm 11y ago
    What? If your intention is to apoligize Google, can you do it in a more clear way?
    - josh2600 11y ago
      I'm not a Google apologist and I don't appreciate your tone. I'm attempting to orient myself so that I can think about what is right and wrong with respect to responsible disclosure in a clear and coherent fashion.
      - adrianlmm 11y ago
        And I don't believe you.
      - ascendantlogic 11y ago
        As stated elsewhere, the original bug was reported in April and not publicly disclosed until July. The issue here is that the patch did not sufficiently remove the flaw. This gets to the crux of the debate on what is "responsible" disclosure. One would assume that the patch would be studied by legitimately malicious attackers and presumably they would independently realize the flaw still existed and continue abusing it. By stating that the flaw is still present the public at large can make educated decisions about their handling of MMS messages instead of assuming everything is fixed when in fact it is not. The flip side is now that less capable malicious attackers will also be made aware. And so the endless argument continues.
  - roblabla 11y ago
    Keeping it secret wouldn't have been very useful. The original issue was already well-known, and seeing the severity and media-exposure of the bug, it is very possible malicious actors studied the patch and independently found out about the problem that came with it. At this point, it is better to let the public at large know they are at risk than let the skiddies have fun with this pseudo-0-day.
  - tossera 11y ago
    The bug is not new after the patch. The patch just failed to fix the original bug.
  - smtddr 11y ago
    This is a grey area. Not everyone is going to agree. For example, if some email client can cause arbitrary command execution by adding a malformed email as CC, like nobody@file:///calc.exe or something, vendor patches it, then the workaround to use the exploit again is nobody@file\:\ / \ / \ /calc.exe , I don't consider that a new bug and doesn't deserve the same grace period for disclosure, IMHO. Now, if it turned out that the email client's ability to show embedded images in the message-body and setting the metadata in a PNG to "file:///calc.exe" caused the calc program to run... I think that IS a new bug and does deserve another grace period because its "point of entry", rendering a PNG and processing its metadata, is very different from parsing the email to/from/cc/bcc fields.
x0x0 11y ago
Eh, fuck google. They still haven't patched the original stagefright for android 4.4.4 on my nexus 5, and I don't want to upgrade to android 5, which I shouldn't be required to do to get security releases.
- ocdtrekkie 11y ago
  Same problem. My options for my Droid Turbo are suffer Android 5.x or get a Windows Phone. ...I'm getting a Windows Phone.
  - bitmapbrother 11y ago
    Because Microsoft is right on top of those Windows Phone updates, right? There are Windows Phones on U.S carriers still sporting Amber.
- matthewmacleod 11y ago
  I shouldn't be required to do to get security releases. Why should you not be required to do that?
  - ocdtrekkie 11y ago
    Because withholding security updates over accepting horrifically invasive UI and branding changes is unacceptable. Similar to Microsoft still patching Vista nearly ten years later, Google should be obligated to deliver security patches to all versions of Android within a reasonable timeframe.
    - oconnor663 11y ago
      I think it's more difficult to patch old versions of Android than you're suggesting. You can't just backport a few lines of code and hope for the best. You have to maintain all the testing infrastructure that you had in place back when that version was supported, to avoid introducing new bugs with your change. And if you're releasing a security fix, you now have to coordinate that release across all versions that were vulnerable, because patching the vulnerability in one version usually discloses it in all versions. So you've slowed down fixes for your most up-to-date version, on top of the added expense of all that testing. Companies like Microsoft make boatloads of money in exchange for supporting old versions of their software like that. But nobody is going to pay Google enough to support old Android phones.

deleted 11y ago

[deleted]

jimrandomh 11y ago

It isn't a new bug; what they're reporting is that the patch which was supposed to fix an already-publicly-disclosed bug doesn't fully fix it.

josh2600 11y ago
Can you help me understand this? They're complaining about a bug in the patch implementation and the patch implementation did not exist prior to the patch; ergo, if Google didn't patch the code, they wouldn't be able to write the article. Is that not a new bug almost definitionally? Please help me understand if I am incorrect. I understand the underlying issue which was first reported did not get patched properly, but, if someone found a bug in the heartbleed patch today and disclosed it immediately with the original patch date as justification, I would imagine many would be screaming bloody murder.
- adrianlmm 11y ago
  What? If your intention is to apoligize Google, can you do it in a more clear way?
  - josh2600 11y ago
    I'm not a Google apologist and I don't appreciate your tone. I'm attempting to orient myself so that I can think about what is right and wrong with respect to responsible disclosure in a clear and coherent fashion.
    - adrianlmm 11y ago
      And I don't believe you.
    - ascendantlogic 11y ago
      As stated elsewhere, the original bug was reported in April and not publicly disclosed until July. The issue here is that the patch did not sufficiently remove the flaw. This gets to the crux of the debate on what is "responsible" disclosure. One would assume that the patch would be studied by legitimately malicious attackers and presumably they would independently realize the flaw still existed and continue abusing it. By stating that the flaw is still present the public at large can make educated decisions about their handling of MMS messages instead of assuming everything is fixed when in fact it is not. The flip side is now that less capable malicious attackers will also be made aware. And so the endless argument continues.
- roblabla 11y ago
  Keeping it secret wouldn't have been very useful. The original issue was already well-known, and seeing the severity and media-exposure of the bug, it is very possible malicious actors studied the patch and independently found out about the problem that came with it. At this point, it is better to let the public at large know they are at risk than let the skiddies have fun with this pseudo-0-day.
- tossera 11y ago
  The bug is not new after the patch. The patch just failed to fix the original bug.
- smtddr 11y ago
  This is a grey area. Not everyone is going to agree. For example, if some email client can cause arbitrary command execution by adding a malformed email as CC, like nobody@file:///calc.exe or something, vendor patches it, then the workaround to use the exploit again is nobody@file\:\ / \ / \ /calc.exe , I don't consider that a new bug and doesn't deserve the same grace period for disclosure, IMHO. Now, if it turned out that the email client's ability to show embedded images in the message-body and setting the metadata in a PNG to "file:///calc.exe" caused the calc program to run... I think that IS a new bug and does deserve another grace period because its "point of entry", rendering a PNG and processing its metadata, is very different from parsing the email to/from/cc/bcc fields.

x0x0 11y ago

Eh, fuck google. They still haven't patched the original stagefright for android 4.4.4 on my nexus 5, and I don't want to upgrade to android 5, which I shouldn't be required to do to get security releases.

ocdtrekkie 11y ago
Same problem. My options for my Droid Turbo are suffer Android 5.x or get a Windows Phone. ...I'm getting a Windows Phone.
- bitmapbrother 11y ago
  Because Microsoft is right on top of those Windows Phone updates, right? There are Windows Phones on U.S carriers still sporting Amber.
matthewmacleod 11y ago
I shouldn't be required to do to get security releases. Why should you not be required to do that?
- ocdtrekkie 11y ago
  Because withholding security updates over accepting horrifically invasive UI and branding changes is unacceptable. Similar to Microsoft still patching Vista nearly ten years later, Google should be obligated to deliver security patches to all versions of Android within a reasonable timeframe.
  - oconnor663 11y ago
    I think it's more difficult to patch old versions of Android than you're suggesting. You can't just backport a few lines of code and hope for the best. You have to maintain all the testing infrastructure that you had in place back when that version was supported, to avoid introducing new bugs with your change. And if you're releasing a security fix, you now have to coordinate that release across all versions that were vulnerable, because patching the vulnerability in one version usually discloses it in all versions. So you've slowed down fixes for your most up-to-date version, on top of the added expense of all that testing. Companies like Microsoft make boatloads of money in exchange for supporting old versions of their software like that. But nobody is going to pay Google enough to support old Android phones.