4 ms·
Are you saying that you are able to read all incoming linux patches, and easily identify changes which fixes a security problem, so that you can come up with a
by marbu 5y ago
Are you saying that you are able to read all incoming linux patches, and easily identify changes which fixes a security problem, so that you can come up with a POC by the time the security issue is announced?
If the patch was flagged as a security problem from the beginning, it would give advantage to attackers, since they would know that the particular patch is worth investigating, while the defenders would have to wait for the patch to be finalized and tested anyway.
- staticassertion 5y agoYou have it completely backwards.
- lmm 5y ago> Are you saying that you are able to read all incoming linux patches, and easily identify changes which fixes a security problem, so that you can come up with a POC by the time the security issue is announced? Their point is that a full-time attacker (and there's enough money in it to do it as a full-time job these days) can look for obfuscated commits and take the time to deobfuscate them, whereas a defender doesn't have that kind of time.
- marbu 5y agoI agree, that is definitely possible. That said it requires lot of work, since there are lot of incoming patches. I wonder how many people would have to review every proposed patch, how to select subset of incoming patches for human review, and how much one have to pay a team doing all this, to get reasonable results and return of investment. My point was that if security patches are flagged as such from the start, it saves attackers lot of time (and money), as they will no longer have to go through (almost) every patch and evaluate whether it could be fixing a security problem. This means that such scenario will get a lot cheaper, while the defenders won't gain much from that, as one still needs to wait for the fix to be finalized and tested before deploying it in a production environment.
- staticassertion 5y agoSecurity researchers already know that they're submitting a patch for a security flaw - there is 0 additional overhead. > My point was that if security patches are flagged as such from the start, it saves attackers lot of time (and money), as they will no longer have to go through (almost) every patch and evaluate whether it could be fixing a security problem. Not really. 1. They can just check to see who made the commit - if it's a security researcher, it's obviously a vuln patch 2. The commits are obfuscated in hilariously obvious ways if you know what to look for 3. It's not that hard to look at a commit, it's kinda what they're paid for > while the defenders won't gain much from that, When the vuln is found a race begins between attacker and defender. The difference is that attackers know they're in a race and defenders find out two weeks later.
- marbu 5y agoThese are interesting points, maybe my assumptions about cost of this analysis are wrong.
- wtarreau 5y agoYour 3 points above are true but this is a perfect example where that didn't apply. A perfectly regular bug found by someone affected by this bug who then started to wonder whether or not it could lead to more interesting effect. Also, the "attackers" you're talking about are more interested in the bugs that are not yet fixed as these ones are more durable. The goal here is mostly to protect against vandals who do not have such skills but find it fun to sabbotage systems. Multiply the max lifetime of critical bugs and the number that are found every year and you'll figure the number of such permanent issue that affect every system and that some people are paid to look for and exploit. This is where their business is. These ones will at best try to sell their exploits when seeing the fix reach stable as they know that within two weeks it won't work anymore, so better get a last opportunity to make money out of it.