>There is no immediate risk of exploitation of these vulnerabilities for most users. Even if the full details were published today, attackers would need to invest significant development efforts to build attack tools that utilize these vulnerabilities. This level of effort is beyond the reach of most attackers...
ToB is right to say this, but it’s not at all uncommon for very serious security vulnerabilities to be “beyond the reach of most attackers.” Browse through Google Project Zero’s blog for examples.
> These types of vulnerabilities should not surprise any security researchers; similar flaws have been found in other embedded systems that have attempted to implement security features. They are the result of simple programming flaws, unclear security boundaries, and insufficient security testing.
Again, correct. However, that describes most serious security vulnerabilities. I’m a security researcher; at this point I’m nearly immune to astonishment about how bad simple programming errors can be. ToB is not insinuating the impact is small, they’re reminding the community that serious problems emerge from seemingly innocuous failures.
For example, I’ve actually witnessed a two-factor auth and password reset system utterly fail and compromise the login interface. A developer wrote “!= 404” instead of “== 200” for the status code handling logic. They forgot the 2fa microservice would return a “429” after five incorrect codes triggered the rate limiter. It was literally a one-line fix. Mistakes don’t get much simpler than that unless you make a typo or off by one error, but it still allowed every single user’s account to be arbitrarily compromised. These mistakes are extremely easy to make the lower down the stack you go.
ToB is right to say this, but it’s not at all uncommon for very serious security vulnerabilities to be “beyond the reach of most attackers.” Browse through Google Project Zero’s blog for examples.
> These types of vulnerabilities should not surprise any security researchers; similar flaws have been found in other embedded systems that have attempted to implement security features. They are the result of simple programming flaws, unclear security boundaries, and insufficient security testing.
Again, correct. However, that describes most serious security vulnerabilities. I’m a security researcher; at this point I’m nearly immune to astonishment about how bad simple programming errors can be. ToB is not insinuating the impact is small, they’re reminding the community that serious problems emerge from seemingly innocuous failures.
For example, I’ve actually witnessed a two-factor auth and password reset system utterly fail and compromise the login interface. A developer wrote “!= 404” instead of “== 200” for the status code handling logic. They forgot the 2fa microservice would return a “429” after five incorrect codes triggered the rate limiter. It was literally a one-line fix. Mistakes don’t get much simpler than that unless you make a typo or off by one error, but it still allowed every single user’s account to be arbitrarily compromised. These mistakes are extremely easy to make the lower down the stack you go.