Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/478 Thanks!
So thank you, so I'm Cheryl
Hudson, and I'm going to be talking about
Thunder Strike two, which is
a firmware vulnerability or a set
of firmware vulnerabilities on Mac books.
You might have seen it in the press has,
you know, the first firmware worm that
affects Macs, that it's,
you know, super stealthy in back doors
them, that it remains
after reformatting and it can be
remotely installed and
it's undetectable and it can't be
removed.
There's a lot of hyperbole in these sort
of press reports, but it is true
that firmware a malware, once it's
installed, is very hard to detect,
very hard to remove.
And that's because it installs in the
spy flash on the motherboard,
also called the boot ram.
And on most systems,
the S.P.I flash is really the root of
trust. This is where all of
everything in
the security of the boot process depends
on the sanctity of the boot
flash.
And because this is
boot, flash contains literally
the first instruction the CPU executes
when it starts up, it's possible
to circumvent any other
software mechanism that attempts
to ensure security.
So one other really important
part about this talk is thunderstruck,
too, is not a new vulnerability.
It's actually built on five previously
disclosed multi-year old
yafai firmware vulnerabilities.
That along with
collaborator's Corey Kaldenberg
and you know, Kova, we are able
to report from commodity PCs
to Mac systems.
And that is the
real key point of this talk, is that
you I firmware vulnerabilities are
shared between these different
systems because they share so much in
common.
You might think that your shiny
MacBook has nothing in common
with some run of the mill commodity
desktop PC.
It has a different motherboard, it has
different OS, it runs
pretty much everything is different, but
under the covers they look very,
very similar that when you disassemble
it, we see the same
sort of code paths, we see the
same functions being called.
We seen the same vulnerabilities
appearing, even though they're built with
different compilers, different
optimization and frequently very
different versions.
There's still a lot of commonality.
And the commonality goes back
to the earliest days of the PC.
IBM's 16 that real
showed bias in the early 80s,
was cloned by Phenix and then everyone
else reverse engineered and cloned
that one.
In 95, Intel started
the Extensible Firmware Interface
Project to try to support new CPU's,
bigger memory, fancier hard
drives and things.
And
in the early 2000s, when Apple
switched over to the the
Intel CPU's, they
forked Intel's F5 standard
and used that for their systems.
A few years later, Intel
transferred all ownership of EFI
to the Unified EFI forum, and that's why
it's called GFI now.
And the forum has continued development,
adding a lot of features, secure boot and
other things.
And they continued development
on this.
We can see that on Christmas Day
there were permits being made to their
country and some of these
are security related.
You know, a suspicious, no pointed
reference could be
a security vulnerability.
So even after
10 years or so of divergence, there's
still millions of lines of code
shared between Apple's F.I.
and the more recent
UAF firmware.
What most from our vendors do is very
similar to what Apple has done.
They for the open source tree,
at whatever version it is, they kind of
freeze at that head.
They ported to hardware platforms and
they sell these packaged firmware.
So when Intel fixes
or excuse me, when the EFI
forum fixes bugs in
the UK to try,
that doesn't mean that all the vendors
have actually done a poll and
and and patched.
And even if they have fixed it on their
new motherboards, they haven't
necessarily fixed it on their decades
of legacy systems.
And even if they've shipped
to firmware update, there's no guarantee
that users install it.
Most people don't install firmware.
And this is an area where Apple has
actually really excelled, that
they are actively pushing for more
updates for systems going back
almost 10 years when
from where security vulnerabilities are
disclosed to them.
So that's enough of the history lesson.
Let's talk a little more about Thunder
Strike two.
As I mentioned, it's built on five
previously disclosed multi-year
old firmware vulnerabilities.
These have been
all the details have been published
going back to 2014, 2013,
some of them as late as as early
as. 2007,
this first one, the Speed Racer,
was presented last year here at 31
C3 by Corey Kahlenberg,
and it is a hardware race condition
that allows in
a multithreaded in a
multi core CPU,
allows a second car to get right access
to the bias.
And the reason for this
goes back to, again, you
know, legacy hardware,
the Intel Interface
Control Hub, was designed for a
single threaded system.
There is the BIOS, right enable bit
that prevents accidental writes
to the firmware. Unless you're in ring
zero.
There's the bias lock enabled bit that
allows Samim to
arbitrate rights
to arbitrate the bias right.
Enable bid when the bit is when the
right enable bid is set to one in
estimate is generated, S.A.M.
gets a chance to decide whether to allow
it and if it doesn't want to allow it,
it sets the bid back to zero.
But that leaves a race condition where
the second thread
has biocide enabled and
turned on for a few cycles.
And he can keep trying and trying
to to write to it
until actually realized this was a
problem in 2004
when they migrated to the platform
controller hub and they added a third
protection bid.
The same bios
protect disable in which
all threads have to be in
the in order to be able to write
to the firmware.
So on a correctly configured system,
the right access
to the firmware is controlled
first by the protected range registers
and then by the seven BWP
bit and then by the BIOS
lock enabled bit.
Corey and his collaborators went
through responsible disclosure and
disclosed all the details to start, and
most of the former
vendors were affected because they had
not updated to
use all of these hardware protection
measures that the that Intel was
providing.
Apple specifically said, however, that
they were not affected.
So we wanted to find out if that
was actually the case.
Going back to the data sheet, we can
read the BIOS control
register, which is
at Offset DC in the
in the hub.
And we can use a tool like Reed Memory,
which is a opensource tool that lets
you read arbitrary
physical memory on those 10.
And what we find is that
it has the value of eight,
and that means that
neither the bios right protect
bit nor the BIOS lock enable
bit or set.
This is, you know, is
not the recommended configuration.
And it turns out that a OS resident
attacker is able to
write a one
to the BIOS. Right. Enable bit and now
they can write to the BIOS.
They can't write to the entire bios
because of the protected range registers,
but it does mean that they can write
and arbitrarily into the invariant
variables.
They can also write to any region
that's not protected by the protected
range registers.
And if you capture
the that portion of the
of the firmware, it actually breaks the
machine so that it is unable to boot.
We went through, again, disclosure with
Apple and they rolled out
a fix and it goes all the way back
to ten, six, eight, which was released
in 2008.
So it's almost eight years of
systems that are that are now protected.
And because Apple does the automatic
rollout, they
these systems for
the most part, have been updated and are
now protected.
One problem is that the fix was it
was just by changing the protected range
register, which means that the
system biosurgery protect is still not
set and the bias
right enabled, it is still vulnerable to
a US resident attacker.
So only the protected range registers are
preventing rights.
Which brings us to our second
vulnerability.
The Darth Phenomics or dark
git Ikoma attack also presented
publicly for the first time last year,
C.C.C.
by Raphel and
some collaborator's.
What they realized is that when the
system goes into a S3
Sasfin to ram sleep,
all of the flash protection bits get
unlocked.
And when the system comes out of sleep,
there's a brief window
that allows an attacker to have write
access to the firmware.
As always, they went through responsible
disclosure and
it turns out that Apple was not contacted
by cert regarding this, but they were
informed through us
to understand how to
take advantage of this vulnerability.
We have to go back to the
the boot script specification,
which describes how
the system, how EFI
goes through a normal boot and then when
it resumes during a normal boot,
the system probes for connected devices,
looks to see what's out there, and it
writes a sort
of a cheat sheet of memory
addresses and configuration
registers into this dispute script.
And then on a resume, it just runs
through the script right into the same
addresses.
Not everything can be expressed in just a
simple right.
So there's a dispatch code that
gives you the ability to put in a
function pointer.
So, again, we can use the
the Reid memory tool to read out the boot
script, which is
actually the pointer to it, is stored in
a environ variable.
And when we pass it, we see
a bunch of those memory rates.
And this right down here is
the one that writes into the protected
range registers and the flock
down bit to to lock them.
But that occurs to late
in the boot script.
We've already had a dispatch
to a function.
And because the Bush script lives in
unprotected memory, we can
use the right meme tool to poke
our own function pointer in there.
And then when the system goes into
sleep, which is a user,
a user command, the system
wakes back up and those protective range
registers are no longer protected,
which allows the resident attacker
to write pretty
much anywhere in the firmware for
for the the CPU, which
again allows it to take control
of the machine from that first
instruction and circumvent
any other chain of trust.
We again went through responsible
disclosure with Apple, and
they, in their note said that
a insufficient lock in the issue existed
and it was addressed through improved
lock in a very
brief comment log there.
There's an additional sleep vulnerability
that we didn't see, but was also fixed
in that patch OS X reverser,
also watched the CCC
talk last year and experimented
on recreating it on his MacBook.
What he found was actually much worse,
that the the S3
implementation left the flash
protection completely unlocked after
a suspended resume cycle.
As you might imagine, that's a bad thing.
And it turns out this is a rediscovery of
a 2013 vulnerability called Snorlax,
in which Dell Systems
failed to properly set Ray
protection after resuming from sleep.
And that was a team ATM that
had found that
the reason that that
we didn't see it in our tests
is that our slightly
newer Mac books had a different Intel
chipset.
And at some point there had been a silent
fix that the
either intel rolled out a
improved reference implementation for
that hardware or Apple fixed
it. But it meant that new machines
were not invulnerable to this this issue.
But older machines were and
no one publicly knew which were
which.
There's a similar silent fix that
happened with the brand new Mac
books, the ones with the USB see
only that it appears to
be using something like Samim
lockbox.
So they're not invulnerable to
the script hijacking.
So, as I mentioned, Apple addressed
the both the
Darth Venomous and the Snorlax
are Prince Charming vulnerabilities
through improved lock in.
What they did is moved the
the code that sets the the lakebeds
and the texture and registers to before
the S3 script is executed.
But the S3 script is still
in unprotected memory and available
for an OS resident attacker to hijack.
They can't use it to
to directly turn off the flash
protection, but there are other
interesting things that this lets you
do prior to the OS Colonel starting
up possibly get into Samim.
I'm still looking into that.
So.
One, you know, with with the easy
routes to getting the flash unlocked,
sort of taken care of, there's
one time when the flash is deliberately
unlocked and that's turning a firmware
update.
So Corey Kahlenberg found
a class of integer overflow
bugs that he was able to write a scanner
for that searched through
lots of different farmers, and he
found a way that
a lot of these vulnerabilities occurred
when the Flash was in a entirely
unlocked state, meaning during
a our update,
one of the machines that he showed this
on was a laptop.
And what's happening
is that the the
length there in the descriptor buffer
is user controlled.
So it's possible to generate an integer
overflow in that length, which then
gives him good execution
while it is passing a firmer update.
So this is this is being run
with the flash unlocked and
gives him full right access.
This affected so many systems that
he won the Tony Award for best privilege
escalation at Black
Hat earlier this year.
As always, responsible disclosure
is really important, and
as you see, almost everyone is affected
except Apple.
Apple claimed
that because they don't use the standard
USSI firmware update routine,
they're not invulnerable to this to this
attack because they have their own
firmware update routine.
If you're interested in that, the Thunder
strike one talk that I gave last year,
C.C.C., goes into extensive
detail about how how Apple does their
firmware updates.
The problem comes that everything
in USA is done
via function pointers and these 128
G.U. IDs, so when
you went to call a function, you
passing this to you ID and it looks it up
on a table and then returns a function
pointer to you, which means that
the linker can't remove
a lot of dead code because
there's a reference to it in this
in this dispatch table.
So the the vulnerable
Fermor capsule update routine
turns out is present in Apple's
ROM.
So even though Apple doesn't use this for
for their firmware updates, the code is
still there.
And through what
what Koreans, you know, called BIOS
necromancy, they were able to generate
a set of inputs that caused that code
to get executed.
So, you know, again, two very
different laptops, but
they share very similar
code in that in that vulnerable
routine.
Obviously, they've been built with
different compilers and different
optimization levels.
But you can see that the
that integer overflow is still
there.
As the result of
our work in proving that and disclosing
it to Apple, they have updated their
status with CERT.
And now a year after it was publicly
announced, they've they've
admitted that they are affected and
they have rolled out a fix.
The particular vulnerability is actually
kind of a very neat
one to to look into that,
you know, unused functions
can contain these vulnerabilities,
legacy functions can contain these
vulnerabilities.
And it becomes really important that when
code is being audited, that both the new
code and this legacy code
gets reviewed and gets updated.
So going back to another legacy
feature, one
that goes back again to the 1980s
with the original IBM PC,
the BIOS at that time
would look on
the motherboard to these expansion from
sockets to see if any optional features
were installed, things like the basic
interpretor, a hard drive controller.
It would also look on the expansion
bus to see if any cards were installed,
like a video card so that it's able to
display the boot messages as well
as the BIOS starts up,
unfortunately. This code is run
in the BIOS and ring zero before
the kernel, and that's really
a bad idea for security.
John Heasman in 2007
showed how this could be used to get
persistance on
on servers with certain network cards.
Snare in 2012
showed how Thunderbolt
is actually Skyy and
it Lud's option.
Rom's off PCI.
My talk at last year at C.C.C.
showed how you could use an option
rom to
during a firmer update to get
code execution with the unlocked
ROM.
And then earlier this year, as
you know, and I presented a class
of vulnerabilities at DEFCON
related to
all of these five that have been fixed.
Following the disclosure at C.C.C.,
Apple rolled out a fix that
partially addressed the Thunder strike.
One issue.
What they changed is that the
system no longer Lud's option ROMs during
firmware updates, which
prevents thunder strike from getting good
execution during
during firmware update.
But it still gives you a way to get
persistance in code running on the
system.
There was a follow on update a little bit
later due to
a rollback vulnerability.
And even with this patch applied,
as I mentioned, you get code execution
during the boot.
So if you have a Thunderbolt adapter,
these Thunderbolt Ethernet adapters
are super popular for this
sort of research.
It runs before the kernel
starts and it's able to log keystrokes
such as the firmware and firewall
password there.
It also gives you a way to get
persistance.
So if you get a remote shell on a system,
you can map all of
physical memory, look for PCI
devices, write your
code into the option ROM on it,
and the next time the system Boutte's
that code is going to run.
This is almost as good persistance as
the API flash.
It doesn't necessarily give you
the ability to circumvent all of the rate
of trust because option rooms are
loaded much later in the boot process.
But it still is a very dangerous
thing to to let happen.
Earlier today, Yohana
Itasca presented something
showing how much writable state there is
in the system, and it's really
scary how many things have
writable firmware blob's,
you know, your fancy Thunderbolt monitor
has an option.
It your
SSD might have an option
Ramonet.
So Intel realized this
was a huge problem and
for the secure boot process, they
required that option.
Rom's be signed.
Unfortunately, Apple has not updated
to a version of you, EFI, that
supports secure boot, so
this is not an option on Apple Systems.
It's also not an option
if your system doesn't support Scherba.
And if someone gets the ability to write
to the firmware, flash on the
motherboard, secure boot won't do
anything for you.
So but the key point
is these are all cross platform
vulnerabilities that were found on
commodity pieces and we were able to port
over to
the to the
Mac platform.
You know, most of them are patched
at this point by Apple.
I've heard that the new IMAX
and some of the newer systems
are no longer an option.
Romes, which I think is great and
upsy C doesn't have option ROMs
yet, but maybe Thunderbolt three will
bring option rooms to USB.
We'll see.
So, you
know, all these vulnerabilities are
there interesting. I'm glad we've got
them fixed, but it was really fun to
package them together into a proof
of concept demo.
So let's let's see,
how could this all come together?
So unlike last year, it
actually can start with a
just a like a software exploit, maybe
software download or a
Adobe Flash
sandbox escape or something that
then can escalate to root with whatever
the root exploit of the day is.
And once it has root, it can
install a kernel module to let it
go, walk through physical memory.
If the system is subject to
Prince Charming, it's able to
immediately write malware into the
motherboard. But flash it
can also then search the PCI
space for devices with option rooms
and write itself into them.
And in this case, the you know, it
found a Thunderbolt Ethernet adapter.
So go ahead and flag that that one's
infected.
And now the next time the
system reboots, the
Thunder strike to prove the concept is
going to be run from the motherboard by
flash.
It's not trying to be stealthy or
anything like that to displace big splash
screen and logo,
and because this runs before
the Austin Kernel has started, it can
do pretty much arbitrary things.
It can get into some it can hide
in virtualization.
It has near total control
of the system. At this point.
If you reinstall OS 10,
it's still there.
You swap out the hard drive.
It's still there.
Because it's it's literally in the
motherboard.
So, you know, if we put
the infected system aside and
but we unplug that infected adapter
into a clean system,
when this one Boutte's, it
loads the option rom off the
off the Thunderbolt adapter.
This is a newer laptop that is not
subject to Prince Charming.
So it can't directly relate to the Flash,
but it can use Darth Phenomenas
to hook the S3 boot script.
And if you can see, it also
reports my firmware password on their.
And then the system continues to boot
normally.
When the system goes into an S3 sleep,
such as when the lid is closed,
the CPUs are going to shut down and
you don't have to open the machine.
I've just done that to show that the
the fans have turned off.
The CPU's are completely powered down
when the system
wakes back up.
The at the S3 script is
executed prior to
the boot being locked.
So it's able to write itself into
the boot flash on the motherboard.
And again, I just flag it so I know which
ones I've infected for clean
up afterwards.
So from the perspective of the the user
of the system, it took just a couple
of extra seconds for it to come out of
that sleep mode.
But nothing out of the ordinary,
so then the next time this system
reboots, it's going to
also display the tabooed screen
logo. So we've now
possibly, you know, infected
another machine via this sort of viral
transmission.
And what's interesting is this didn't
touch the OS at all.
This was completely at a level
below the operating system.
One of the other things that thunder
strike to prove concept does
is it watches for the PC hop plug event.
So when a when a clean adapters
plugged in, it detects that
and the interrupt handler writes
the option wrong to the device.
So this allows it to potentially spread
and potentially cross AACAP security
measures. And so if you
have a uranium centrifuge
plant that you're trying to get into,
this might be one of those ways to do it.
So the
proof of concept is is showing a really
neat sort of life cycle for this kind of
malware going from software
exploit that's able to escalate
into the flash or the option rom
Hook S3 again, DMM,
and then go and infect other machines in
the booth flash.
And once it's in that sort of boot slash
option rom com space,
it's completely underneath the OS.
So most virus scanners
aren't even looking for it and probably
couldn't even see it because they have
the ability to trap all
of this memory references and hide
from from normal scanning techniques.
Pretty much the only way you could see if
it's in the flash would be to
put a chip clip on the
on the on the
flash there and read it out and
hope that nothing is interfering with
that.
You know, any attempt to do in software
is going to be masked by the by
the proof of concept.
So Johanna presented
a lot of ideas about things we could do
to deal
with the inevitable inevitability
of rootkit and firmware issues,
you know, attempts to try to move it
outside the system.
But there are a lot of smaller
steps we can take as well,
things like checking the signatures on
the option ROMs or not even loading
option ROMs. This is a really big
first step.
Using all of the locks that the platform
provides, you know, is
really key, making sure that the BIOS
is not readable to resident
attackers, making sure that they
can't hook these three boot script
to get into some.
You know, Intel has added features to
Wi-Fi, like the SIM lockbox
that allowed these three boot script to
be protected from attackers.
And there are tools like Chips and
Copernicus that can
help validate these configurations
to make sure that the systems are being
rebooted and run in a
safe manner.
Intel is also continuing some
hardware attempts, some of their newer
CPUs have a feature called Beaugard,
and this adds actual
ROM for the first instructions
the CPU executes, which
is sufficient to do a cryptographic
verification of the boot flash
before executing any code out of it.
This is great for security, but
unfortunately, this locks out
free software developers, so
systems with boot guard are are
fundamentally incompatible with
with core boot.
And there's that's
a really difficult move
for for software freedom,
even if it does provide a good
level of protection.
And my plea to
system vendors is
that when
new vulnerabilities are disclosed, that
you need to really work with researchers
to try to figure out if they're
vulnerable.
I read a lot of proof of concepts and
they're really difficult to get working
on one machine, much less a
range of machines.
So sometimes vendors take a
proof of concept. They run it on their
system.
It doesn't work. And they say, oh, we're
not vulnerable and there's really not
any
risk to them for doing that.
So, you know, it would be great if
Endres were more proactive in working
with researchers on helping to port
these things and find that out,
the legacy code, you know, as Cory found,
there's a lot of code dead code
in EFI that may have
vulnerabilities.
And even if you
do you think that your system's not
running it, it might be possible
with a set of inputs to to
get the code to jump into it.
It's super important to test the full
cross cross product of
old vulnerabilities and systems
that things like Snorlax been
an old vulnerability that reappeared a
few years later is actually really
kind of scary.
Know that there was we learned
about a really serious bug and
systems got fixed and then new systems
got produced that were still vulnerable
to that old to that old bug.
That that's a problem.
Likewise, new vulnerabilities
might a lot of times they don't
necessarily get tested against older
systems. So we don't know
what machines are actually vulnerable
other than the current generation of
machines.
And, you know, please, if
you're in an opportunity to to
fix security vulnerabilities, don't just
do it silently. Make sure that people
know, you know, these are the
keys that are being patched against.
These are the things that that
are being changed.
And what what
systems will actually be secure against
is when we're in the dark with this, it's
really dangerous. We don't know if
we're going to
you know, just because my machines two
years old and you've got a newer machine,
it's dangerous for for
for us to not have that certainty.
So on
that, I'd love to open
up for some questions.
There's a lot more details about the
vulnerabilities on my website.
I'm also happy to take a
GPG emails and
continue the discussion on these
Fermor topics.
I think, you know.
I think the battery's dead.
OK, let's do this without the mic for a
second. Now we're going to take you can
try that one.
Yes, we should be on tape.
Thank you.
Not for you guys, but for the people
out there in the street.
So we're going to do a little question
talk
and we'll do one question from the
room. One question from
the Web. And then again, the question
from the room. So are there any questions
out there?
Yep, Mike, three, please.
Yes.
Have you seen actual spy
flesh iRace Ackermans
going to your flesh chips or how how is
it actually managed on the background
with different spy flesh
chips?
Are you asking does the OS
periodically do traces of some sort?
Well, how because to
try to flash, you also have to erase
Flash first before you can write it,
right? That's right.
So for things like the the invariant
variables and
there's a related question of why does
Apple leave the flash
rideable and they store in
the nonvolatile variables
in in the Flash.
So things like what is your screen
brightness? What it was the last Wi-Fi
network and credentials that you logged
into are stored in
the in the environment and
it's stored in a
in a log, a pin structure.
So you can add items
to it and then they can
set individual bits to mark
to tombstone old values.
And once they fill up a block then they
they will do a full race rewrite cycle.
But typically they just do
append and then tombstone marking.
OK, do we have a question
from the Internet?
Is there anybody out there?
Yeah, yeah, go ahead.
Um, how is Boogaard
related or different to the trusted
platform module?
So the trusted platform module is
unfortunately not.
It assumes that the Flash
is protected, that
the trusted platform module is outside
the CPU, so
and it only signs
or it only generates hashes
based on what the CPU has asked
it to do.
So if you have malware that
has taken over the spy flash,
it is able to
send whatever values it wants to the TPM
that the TPM can't look at memory.
The TPM can't look at the state of the
CPU.
The TPM only hashes what's
given to it.
So Buchard moves the trust inside
the CPU, so it's no longer having to
go to this outside device.
And because boot guard doesn't
even start executing code from
the flash until it verifies it.
This means that a
malicious attempt to modify the flash
will be detected or will
be detected on the next boot,
you know for sure.
I don't remember if they have the sort
of soft feel versus hard fail in
the Boukhari implementation.
But yet the
TPM unfortunately, was a
an interesting idea.
But there's probably a dozen
or two dozen papers on how to defeat it
and get around it in different ways.
OK, then a question from Mike three,
I am I
have had my own share, was
reporting back to Apple and getting
some feedback and making sure that
they actually fix it the way that I
thought it should be fixed.
But I see that you
seem to have that in a repetitive
pattern, that they
thought they fixed it, they didn't
consult with you, and they
released a fix. And then you found out,
oh, no, it didn't work.
Is that kind of I mean,
is I would expect
that this is such a sensitive area
where what Apple would really want to
have a dialog with you that never happen
or what a miscommunication.
It's happened on some of the bugs.
They there has been a good dialog.
And we've had they have sent mediators
to test and we've had back and forth
occasionally things have
been put out before.
We've had a chance to do that.
And sometimes.
Yes, sometimes the dialog takes takes
longer than they want to
wait for the fix, although I do have
really good hopes, they
just acquired
Zino Inquiries, a company like
Bacau.
So I'm really hoping that this means that
Apple's former security is going to go
even better than than it's been in the
past few years.
One more question from the net
note, do you have a tool to check
the current state of the the MacBook,
like if it's vulnerable or not?
The the difficulty
with ascertaining if the system is
currently vulnerable or currently
infected is that a
a a sufficiently
stealthy malware can trap
all attempts to read the ROM and read
the state of things.
So if it's been able to infect the
system, it's very, very difficult
to even tell if that's happened.
Tools like Chip Sech will
attempt to tell you if the system is
in a vulnerable state.
And that's one way to say
if you with a clean system, you
can check to see if it's
whether or not it looks like it's good.
But if you've had a system that you think
has been infected, it's
very difficult to say.
OK, is there one more
question from the net, otherwise we're
going to call this a baby.
OK, there's one more question from the
net.
What platform which
would you recommend to avoid if
you if I both systems
and which are nearly as compatible
to our normal computers?
Well, you EFI is making
its way into the arm world now, so
I'm not sure if it's possible to avoid
you efi in its entirety,
the UBI itself
that somewhat of a good thing.
It is extensible. It is nice to have
a lot of that functionality, but it is
a huge amount of code and the trusted
computing base.
And, you know, as most
security researchers will tell you, that
that is problematic.
But at this point, it looks like all the
hardware is going to be you F.I.
in the foreseeable future.
I do have good hopes for things like
Bunyan's laptop,
open source hardware, a laptop with
entirely open source firmware,
because that at least means that we're
not running a bunch of
proprietary binary blob's
things like the intel management engine
are, you know, certainly,
you know, it's
we just don't know anything about what's
going on inside of it and what it might
be doing.
So even if you
have secure firmware, you've got
a binary blob running that might be doing
something that you don't want.
And that's a somewhat
of a difficult situation to be in.
OK, let's have a
final hand for trommel.