On Thu, 04 Jan 2018 12:18:17 -0500, Virus  wrote:

> David W. Hodgins wrote:
>
>>> I'd like to see a complete breakdown of the status of all Intel CPU's,
>>> going back to at least the SLOT-1 products and including socket 370,
>>> socket 478 and socket 775.
>>
>> Unlikely that there will be such a list. All cpus are affected.
>
> Well, they do say that anything prior to 1995, and (in the case of Intel
> Atom) prior to 2013.  I have some Atom-powered netbooks that would
> therefore not be vulnerable.

All cpus that use speculative execution. There aren't many still in use
that don't.

>> It provides read access to tiny amounts of data at a time. Given the
>> multi-processor/multi-threading of processors, the volume of data the
>> exploit would have to sift through to find any thing of use, is massive.
>
> That's one thing I don't understand, based on current reports.

> Do operating systems of any or all sorts keep passwords in "special",
> strategic or universally-accepted locations in RAM such that sifting
> through gb worth of memory dump would not be required?

No. Using aslr, the kernel modules will be in different places in ram
every boot. Keep in mind, most applications that process passwords do
it in the application, not explicitly in the kernel.

> To just even go about excercising the vulnerability, would the required
> code be so specifically crafted such that the exact model/type of CPU
> AND the particular OS would both be needed to be known in order for the
> code to perform the intended memory dump operation?

Again, going based on what I've read, any exploit would require
customization based on the cpu family. As the exploit does not take
advantage of any vulnerabilities in the kernel or other software on
the system, it just has to be able to execute on that cpu. It's by
running the exploit code in parallel to code being run by the kernel,
on the same cpu that it gains access.

> Would there be any quirks of particular operating systems that would
> render this vulnerability of little or no value, because of workability
> issues?  I'm thinking of differences between, say, Win-9x/me vs any of
> the NT-based Windoze.  Differences in how memory is used by the kernel,
> etc.

No. If the code can run on that cpu, the os doesn't matter in any way,
except for how it's kernel uses the cpu.

> I don't believe that win-9x/me has any notion or ability to separate
> memory access between applications, and I've never heard of any sort of
> "password" attack or comprimize that is specific to 9x/me that has any
> relavence to a user system.

With win-9x/me, I expect most of the code runs outside of ring 0, making
the os much more vulnerable to other exploits anyway. Those are single
user operating systems, so all programs have full access to everything.
Such an operating system should never be used for anything requiring
any security. Never enter a password, account number, etc., if using
such an os, unless it is air gapped from the internet.

Without more details on how an exploit does work, I'm speculating based
on what has been published.

See https://en.wikipedia.org/wiki/Protection_ring
The kernel code running in run level 0 has to communicate with software
running in other levels.

My understanding is that by abusing speculative execution, a program
can gain some access to what the results of another programs instructions
would have put into it's registers. What I've read indicates to me that
they are talking about registers, not ram, so it's very tiny amounts of
data at a time.

While I can see how a proof of concept showing that some data is made
accessible, that shouldn't be, has likely been made, I currently do not
see how that could be made into a useful exploit. I could be completely
wrong about the impact, but that's my current understanding.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.
--- NewsGate v1.0 gamma 2