6 ms·

They sure are valuable, he never said otherwise. His point was that the PoC exploit was released before or right at the time that patches became available and d

• emidln 11y ago
  Delaying PoC doesn't preclude others from analyzing the patch and writing exploits. The only thing delaying PoC does is provide a false sense of security.
  • dimman 11y ago
    No, analyzing a released patch and then write an exploit takes time. Compare that with taking a pre-written exploit and executing it, so it has nothing to do with "false sense of security". Fact is that it gives people more time to patch their systems.
    • emidln 11y ago
      There is no basis in the statement that witholding gives people more time to patch their systems. Even if these authors don't release their PoC, there isn't any way to prove it isn't already known to bad actors. Without the PoC, it is more difficult for legitimate users, particularly legit users with custom deployments, to know if they are vulnerable and to verify that patches actually fix the problem.
      • nickpsecurity 11y ago
        There's two options available: release patch and exploit simultaneously where bad guys all over the place can exploit users easily before their patch testing or deployment happens; release patch and delay exploit release so that only the subset R.E.ing the patch and converting it to a payload can hit whoever they chose to hit. One choice puts a lot of risk on the users of software. One choice puts way less. You're constantly encouraging putting more risk on users and exploits into arbitrary attackers' hands with the argument that one or more attackers might already be a risk. That makes no sense. The only people with a straight-up benefit from this are malware writers who don't want to work very hard converting the patch into an exploit. Researchers should delay the publishing of exploits at least a week so people can test and deploy the patch. I keep mentioning testing because patches sometimes break stuff themselves. Doing otherwise just saves attackers work.
        • emidln 11y ago
          As a user, how do I know that the patch I applied fixes the issue, particularly given the potential for user configuration of the software receiving patches? I need a PoC so I can verify the fix for the machines I'm responsible for.
          • nickpsecurity 11y ago
            As a user, you have to choose between different risks: the risk of attackers using easily-made exploits to hit a known flaw; the risk that they issued a patch that doesn't patch. One sounds much more serious than the other. Further, you can test the patch after the exploit is released later. Instead, you want to acquire immediate vulnerability to a large group of hackers to prevent a patch from maybe making you vulnerable to a smaller number that either has an existing exploit or RE'd the non-working patch to devise a new one. Makes no sense lol... Better to get the patch, do basic tests to ensure it doesn't break functionality, install it, monitor the system/network, and then verify the security later when the sploit is released.
  • goshx 11y ago
    Needless to say, but analyzing the patch and writing the exploit is a lot more involved than copying, compiling and running an exploit, like 90% of the attackers (script kiddies) do. What they did here was simply irresponsible at best.
  • thesteamboat 11y ago
    Delaying PoC raises the cost of exploiting the vulnerability; having it makes it easier to exploit and not having it means an attacker needs to invest resources recreating it. How much this helps depends on a lot of factors, but it doesn't seem unreasonable to me to allow some time for users to patch before releasing the PoC.
  • danielweber 11y ago
    I wish people would actually think about issues before saying "false sense of security." It's as useless as shouting "that's security through obscurity!" without thinking about things. If you want to get rid of the False Sense Of Security, announce that there are working exploits out there.
    • emidln 11y ago
      The rationale for not releasing the PoC is that it gives legit users a chance to patch. This ignores the possibility of an attacker quickly developing an exploit as well as ignoring the scenario where bad actors already know and are exploiting the vulnerability. Not releasing PoC allows users think they have more time to patch than they actually do. This is a sense of security that is not actually derived from being secure in any way. What else should I call it? This also prevents users from being able to test their machines vulnerability after patching to verify that the patch remedies the problem in their installation. Again, apply the patch, hope that it works in my installation (with my config options) is a piss poor security policy.
      • danielweber 11y ago
        > Not releasing PoC allows users think they have more time to patch than they actually do This assumes a bunch of stuff about the psychology of everyone else that you cannot possibly know. You are making decisions for other people because you think you know their business better than they actually do. > This is a sense of security You are not a telepath who can read people's minds.
• Titanous 11y ago
  Yes, and my argument is that providing a working PoC along with a patch has at least these immediate benefits: 1) It helps admins verify that the patch was successfully applied. 2) It gives security researchers more surface area to evaluate when looking for similar bugs or bugs in the patch. I'm not asserting that there are not negative aspects, but in the majority of cases waiting for some indeterminate time before releasing a PoC or not releasing one at all is net negative.