3 ms·

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 wi

by 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.

by dimman 11y ago

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.