By: anon2 (anon.delete@this.anon.com), July 14, 2022 6:40 pm
Room: Moderated Discussions
anon2 (anon.delete@this.anon.com) on July 14, 2022 5:37 pm wrote:
> Anon4 (No.delete@this.example.com) on July 14, 2022 5:05 pm wrote:
> > anon2 (anon.delete@this.anon.com) on July 14, 2022 4:29 pm wrote:
> > > No it wasn't, it was BTB poisoning to influence indirect branches.
> > > Branch direction forwards or backwads is not relevant.
> >
> > I've had my head to much on CFI recently.... forward edge, obviously branch direction is not relevant.
>
> There seems to be nothing about "forward edge" in spectre vulnerability. It is about indirect
> branches which use the BTB, return branches can be such indirect branches on these CPUs.
>
> >
> > > Some CPUs use BTB for return branches in some situations. This is not somehow new nor was unknown at the
> > > time. It was explicitly called out in a public discussion about the fix several years ago, actually.
> >
> > And was thought not to be exploitable, some people thought it was exploitable
>
> That's what I said. Nothing new from hardware standpoint, the only problem is incomplete mitigation
> for spectre v2. Or if you really want to quibble about semantics, the fact remains that the exact problem
> was known about and called out when the fix was being discussed. No new hardware vulnerability discovery,
> this is exploitation of known hole in known incomplete software fix for spectre v2.
>
> > however they could not come up with a practical attack at the time.
> >
> > Given the mitigation cost no one was going to roll out an expensive speculative (sic) mitigation against
> > an attack which was not thought to be practical at the time. That 'expensive' is in money, performance
> > losses cost real money for the hyperscalers and major ones can make a service economically unviable.
>
> Aside, many such security issues that are fixed have *actual* practical attacks
Correction: Do NOT have actual practical attacks demonstrated.
They may jump through very careful hoops to make it appear as though they have demonstrated a practical attack, for example implementing a PoC that gets around some particular data protection mechanism and do it in Javascript and have it work in laboratory conditions, and then draw insinuations or imply (or allow the "tech" press to draw the line) that therefore if you click on a web page it can steal your credit card number and bitcoins.
Of course this is all great business for "security researcher" job security so they do it deliberately and very few have any intention to even try to develop objective metrics, publish retrospectives showing how much these security issues are exploited, or give reasonable advice such as don't use hardware shared with untrusted user if you are paranoid and don't trust that we found all problems and didn't make multi-year mistakes on issues such as this one.
/end rant
> demonstrated. Most of this security patching and mitigation has no objective
> measurement or even metrics that can inform the benefit of fixes.
> Anon4 (No.delete@this.example.com) on July 14, 2022 5:05 pm wrote:
> > anon2 (anon.delete@this.anon.com) on July 14, 2022 4:29 pm wrote:
> > > No it wasn't, it was BTB poisoning to influence indirect branches.
> > > Branch direction forwards or backwads is not relevant.
> >
> > I've had my head to much on CFI recently.... forward edge, obviously branch direction is not relevant.
>
> There seems to be nothing about "forward edge" in spectre vulnerability. It is about indirect
> branches which use the BTB, return branches can be such indirect branches on these CPUs.
>
> >
> > > Some CPUs use BTB for return branches in some situations. This is not somehow new nor was unknown at the
> > > time. It was explicitly called out in a public discussion about the fix several years ago, actually.
> >
> > And was thought not to be exploitable, some people thought it was exploitable
>
> That's what I said. Nothing new from hardware standpoint, the only problem is incomplete mitigation
> for spectre v2. Or if you really want to quibble about semantics, the fact remains that the exact problem
> was known about and called out when the fix was being discussed. No new hardware vulnerability discovery,
> this is exploitation of known hole in known incomplete software fix for spectre v2.
>
> > however they could not come up with a practical attack at the time.
> >
> > Given the mitigation cost no one was going to roll out an expensive speculative (sic) mitigation against
> > an attack which was not thought to be practical at the time. That 'expensive' is in money, performance
> > losses cost real money for the hyperscalers and major ones can make a service economically unviable.
>
> Aside, many such security issues that are fixed have *actual* practical attacks
Correction: Do NOT have actual practical attacks demonstrated.
They may jump through very careful hoops to make it appear as though they have demonstrated a practical attack, for example implementing a PoC that gets around some particular data protection mechanism and do it in Javascript and have it work in laboratory conditions, and then draw insinuations or imply (or allow the "tech" press to draw the line) that therefore if you click on a web page it can steal your credit card number and bitcoins.
Of course this is all great business for "security researcher" job security so they do it deliberately and very few have any intention to even try to develop objective metrics, publish retrospectives showing how much these security issues are exploited, or give reasonable advice such as don't use hardware shared with untrusted user if you are paranoid and don't trust that we found all problems and didn't make multi-year mistakes on issues such as this one.
/end rant
> demonstrated. Most of this security patching and mitigation has no objective
> measurement or even metrics that can inform the benefit of fixes.
Topic | Posted By | Date |
---|---|---|
Retbleed | anonymous2 | 2022/07/13 03:14 PM |
Retbleed | anon2 | 2022/07/13 10:03 PM |
Retbleed | Adrian | 2022/07/14 12:05 AM |
Retbleed | Anon4 | 2022/07/14 02:17 PM |
Retbleed | anon2 | 2022/07/14 04:29 PM |
Retbleed | Anon4 | 2022/07/14 05:05 PM |
Retbleed | anon2 | 2022/07/14 05:37 PM |
Retbleed | anon2 | 2022/07/14 06:40 PM |
Retbleed | dmcq | 2022/07/15 04:54 AM |
Retbleed | anon2 | 2022/07/17 07:17 AM |
Retbleed | Michael S | 2022/07/15 07:08 AM |
Retbleed | Ben T | 2022/07/16 05:06 AM |
Retbleed | Michael S | 2022/07/16 11:41 AM |
Public cloud infrastructure | Ben T | 2022/07/16 04:50 PM |
Public cloud infrastructure | Rayla | 2022/07/16 09:15 PM |
Public cloud infrastructure | me | 2022/07/17 09:19 AM |
Public cloud infrastructure | Brett | 2022/07/18 12:38 PM |
Public cloud infrastructure | Adrian | 2022/07/18 01:19 PM |
Public cloud infrastructure | me | 2022/07/18 03:54 PM |
Public cloud infrastructure | Brett | 2022/07/20 03:35 PM |
Public cloud infrastructure | Brett | 2022/07/21 01:18 PM |
Public cloud infrastructure | inthestratosphere | 2022/07/21 02:46 PM |
Public cloud infrastructure | Brett | 2022/07/21 10:38 PM |
What’s needed for a viable Apple server? | Ben T | 2022/07/22 05:31 AM |
What’s needed for a viable Apple server? | Michael S | 2022/07/22 09:09 AM |
More DRAM capacity? | Mark Roulo | 2022/07/22 09:48 AM |
More DRAM capacity? | Doug S | 2022/07/22 11:05 AM |
More DRAM capacity? | Mark Roulo | 2022/07/22 11:20 AM |
More DRAM capacity? | Doug S | 2022/07/22 01:48 PM |
More DRAM capacity? | Wes Felter | 2022/07/22 04:49 PM |
Public cloud infrastructure | anon2 | 2022/07/18 04:25 PM |
Putting 12 processor packages in a 1U server | Ben T | 2022/07/22 10:02 PM |
Putting 12 processor packages in a 1U server | rwessel | 2022/07/23 07:15 AM |
Putting 12 processor packages in a 1U server | Daniel B | 2022/07/23 04:15 PM |
Putting 12 processor packages in a 1U server | Ben T | 2022/07/24 05:29 AM |
Multi-system cluster design space | Paul A. Clayton | 2022/07/24 08:49 AM |
Retbleed | Anon4 | 2022/07/15 03:00 AM |
Retbleed | Michael S | 2022/07/15 06:59 AM |
Retbleed | --- | 2022/07/15 11:14 AM |