Sorry guys, you just convinced me that no one, not the NSA, not the FSB, no
one!, has in the past, or will in the future be able to exploit this to actually
do something not nice.
I'm not saying that the hardware shouldn't be fixed, I am saying that we
don't need to worry about this.
In the early days of DOS their was a hardware bug in nearly all floppy
controllers, it wasn't even discovered until (I think,) 1985 or so.? The
thing is..., no one reported unusual problems.
So what is this, really?, it's a market exploit opportunity for AMD.
On Friday, January 5, 2018, 3:33:31 AM EST, Ronald F. Guilmette <rfg at
tristatelogic.com> wrote:
In message <736a2b77-d4a0-b03f-8a6b-6a717f5744d4 at metricspace.net>,
Eric McCorkle <eric at metricspace.net> wrote:
>The attack looks like this:
>
>1) Fetch kernel/other process memory, which eventually faults
>2) Do a bit-shift/mask operation to pluck out one bit of the fetched
>value.? This gets executed speculatively on the fetched value in (1).
>3) Execute fetches of two different addresses depending on some bit in
>the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1).? This
>also gets executed speculatively despite the fact that (1) ends up faulting.
>4) Recover from fault in (1)
>5) Measure performance of accesses to the two addresses to determine
>which one is cached.
I must say, that's one hell of a round-about way to read just one bit that
you wern't supposed to have access to.? But of course, that doesn't
really
matter if you are an attacker.
If the above steps can be repeated, programatically, ad infinitum, to read
bits from "protected" memory... and I see no reason why they can't
be...
then yea, this bug is every bit as bad as the media is making it out to be,
and maybe even worse.
All your secrets are belong to us!
Time to invest in abacuses... or is that abacai?
Regards,
rfg
_______________________________________________
freebsd-security at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe at
freebsd.org"
Hello, On 05.01.2018 11:07, Jules Gilbert via freebsd-security wrote:> Sorry guys, you just convinced me that no one, not the NSA, not the FSB, no one!, has in the past, or will in the future be able to exploit this to actually do something not nice. > I'm not saying that the hardware shouldn't be fixed, I am saying that we don't need to worry about this.we should indeed worry about this. This could be just the tip of the iceberg. Think about Rowhammer. This was a bug which affected RAM. In the beginning it was just some basic computer science research which was hard to trigger. After some month people found ways to exploit Rowhammer via JavaScript so that every person using a browser was a possible target. The same could happen with this stuff, people are already working on this. Best, Karsten> In the early days of DOS their was a hardware bug in nearly all floppy controllers, it wasn't even discovered until (I think,) 1985 or so.? The thing is..., no one reported unusual problems. > So what is this, really?, it's a market exploit opportunity for AMD. > > > > On Friday, January 5, 2018, 3:33:31 AM EST, Ronald F. Guilmette <rfg at tristatelogic.com> wrote: > > > In message <736a2b77-d4a0-b03f-8a6b-6a717f5744d4 at metricspace.net>, > Eric McCorkle <eric at metricspace.net> wrote: > >> The attack looks like this: >> >> 1) Fetch kernel/other process memory, which eventually faults >> 2) Do a bit-shift/mask operation to pluck out one bit of the fetched >> value.? This gets executed speculatively on the fetched value in (1). >> 3) Execute fetches of two different addresses depending on some bit in >> the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1).? This >> also gets executed speculatively despite the fact that (1) ends up faulting. >> 4) Recover from fault in (1) >> 5) Measure performance of accesses to the two addresses to determine >> which one is cached. > > > I must say, that's one hell of a round-about way to read just one bit that > you wern't supposed to have access to.? But of course, that doesn't really > matter if you are an attacker. > > If the above steps can be repeated, programatically, ad infinitum, to read > bits from "protected" memory... and I see no reason why they can't be... > then yea, this bug is every bit as bad as the media is making it out to be, > and maybe even worse. > > All your secrets are belong to us! > > Time to invest in abacuses... or is that abacai? > > > Regards, > rfg > _______________________________________________ > freebsd-security at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org" > > _______________________________________________ > freebsd-security at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org" >
On 01/05/2018 05:07, Jules Gilbert wrote:> Sorry guys, you just convinced me that no one, not the NSA, not the FSB, > no one!, has in the past, or will in the future be able to exploit this > to actually do something not nice.Attacks have already been demonstrated, pulling secrets out of kernel space with meltdown and http headers/passwords out of a browser with spectre. Javascript PoCs are already in existence, and we can expect them to find their way into adware-based malware within a week or two. Also, I'd be willing to bet you a year's rent that certain three-letter organizations have known about and used this for some time.> So what is this, really?, it's a market exploit opportunity for AMD.Don't bet on it. There's reports of AMD vulnerabilities, also for ARM. I doubt any major architecture is going to make it out unscathed. (But if one does, my money's on Power)
Jules Gilbert <repeatable_compression at yahoo.com> writes:> Sorry guys, you just convinced me that no one, not the NSA, not the > FSB, no one!, has in the past, or will in the future be able to > exploit this to actually do something not nice.The technique has already been proven by multiple independent parties to work quite well, allowing an attacker to read kernel memory at speeds of up to 500 kB/s. But I guess you know better... DES -- Dag-Erling Sm?rgrav - des at des.no