News for hackers. Stuff that matters.
Re:Our Interesting Call with CTS-Labs by asimov42 on Thursday March 15, 2018 @11:51PM (#16598486)
According to Trail of Bits :

"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 (see https://www.usenix.org/system/files/1401_08-12_mickens.pdf, Figure 1)

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." - https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-...

Re:Our Interesting Call with CTS-Labs by dsacco on Thursday March 15, 2018 @11:58PM (#16598516)
>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.

Re:Our Interesting Call with CTS-Labs by baby on Friday March 16, 2018 @05:54AM (#16599606)
Your last example is why you should always use whitelists instead of blacklists.