From: "David W. Hodgins" <
dwhodgins@nomail.afraid.org>
On Thu, 04 Jan 2018 12:18:17 -0500, Virus <
Virus@guy.c0m> 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
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)