we are going to kick off our Talk's
today with Alex Morozov from silence he
wrote a book called boot kits root kits
and boot kits that backwards or forwards
and he's going to talk to us today about
subverting the BIOS I know you've all
had lunch so stay awake and enjoy the
talk hello everyone my name is Alex
Marat Safin and I will present him today
between the bias where the guardians of
the virus failing so actually the talk
will be focusing on some of the
technologies which is supposed to
protect the firm where you fight firmer
specifically and this kind of treads
actually always under the radar of
normal malicious and to our normal
security software and antivirus software
and also actually this research being
done for blackhat where I guess this
year for specifically for blue hat it
will be a bit extended and also I'm
currently actually leading embedded
security at Nvidia but before of that I
actually been at silence as principal
security researcher and this research
being done at the science time before of
that I actually been a security lead for
Intel ufi firmware security and yeah I
actually out one of the outers of the
boot boot kids and rootkits advanced it
more analysis so what we are talking
about today so we will start about the
attacks on the BIOS update and how
actually the updates for the you fight
firmware is failing and why is it it is
failing it which kind of attacks that
hacker can use it for get in without
physical access and after that I will
explain first known into boot guard
attack and it is technology which is
actually protect the secure boot from
the hardware side and specifically I
will focus on american megatrends
implementation and we will talking about
how the technology works and where is it
like sensitive places and
how the attacker can actually bypass
this technology and discuss the wounds
which is I use it for bypass it and I
will give you details about some BIOS
guard implementation - so boot guard
it's totally actually undocumented
technology and if you interested it will
be some details which is actually not
published before my talk at blackhat and
today I will also talk about the - which
is make some validation for the endo
boot guard but let's start from the
beginning so why actually the bias is
very interesting place for the route
kids in the past time actually a rootkit
started from Realtree and just like load
some malicious driver inside the kernel
or like abuse some driver objects inside
the kernel and after some time when the
secure boot and code sign and policies
for kernel what driver appears its
before secure boot actually appears it's
it been a time for the boot boot kids
because like attacker start thinking how
how we can actually get in and get a
lipid a little bit deeper with the
system boot flow and attack the MBR a
Master Boot Record and volume Boot
Record and okay but after that in 2012
the secure boot been introduced and in
nowadays actually all the systems came
with active secure boot and it's very
but some some cases with wanna cry and
other malicious dresses show so I ran
somewhere shows like it's still a lot of
systems which is doesn't use the secure
boot read but it's supposed to be there
and if we're thinking about work very
complex sophisticated treads and it can
be biased and specifically for like data
centers and the clouds it's very
sensitive place if the attacker came
with supply and chain attack on the
server inside the firmware this can
expose all the guests
on the server if it will be like no
specific protections like memory
encryption or something else right so
very interesting place for the attacker
its system management mode which is
currently one of the most privileged it
mods inside inside the intel x86
architecture and actually why is the
last line showing like we're going from
system management mode to the operating
system level to rank zero because
actually yes you can parse all the
physical memory from there but if you
want to track some specific applications
it's very interesting to be present on
the operating system level and it's
actually not difficult to inject some
some malicious drivers or something else
from this level because you control of
the memory space and you can just like
modify some structures if it will be not
no integrity checks and I want to say
actually as more mitigation we have as
more complexities growth so currently
all the route kids it's growing closer
and closer to hardware we have from some
like known cases examples like our LK
loader from hacking team or some implant
which has been disclosed with world 7
leaks and this kind of treads actually
can bypass all the modern mitigations if
the bias doesn't have any protections or
deliver unsign and updates right so and
this why it's actually I copied from the
presentation from Intel which has been
presented in this black hat and we can
see like a growth of the bias incidence
which is actually been involved with the
enthalpy chart and interesting think
actually configuration configuration of
waste issues
has a very high rate here when like the
platform has the issues and by default
configure unsecure way and it's actually
very very bad when this kind of things
happens because for supply chain attacks
it the perfect vector right and Google
introduces a cheap which is Google
Chetan recently and it's very interested
in case when the company developed
something for like armoring root of
trust on the hardware side because if it
doesn't trust the hardware how we can
protect protect root of trust for the
secure boot and other things and trust
like peripheral devices they're right
somebody just inject just install like
beside wise and then get access to visit
G my attack if it will be like unsecured
way or VTD will be doesn't ensure
initialized very early so it's very
interesting case where where the company
not really related with this like
hardware development or related with ik
and customers things like big cells but
develop the chip which is actually
protects the root of trust I I like this
approach but I also very interested to
get one for working house can break it
so yeah let's talk a bit about the BIOS
update issues u5 firmware actually it's
very huge if I firmware ecosystem is
very huge now its automotive and
actually it's not only x86 system it's a
lot of arm CPUs developers like
companies use EFI firmware too and it's
like very very huge world and some of
the companies actually developed some
frameworks like american megatrends
insight and phoenix and on top of these
frameworks companies developed the
olan firmware and a lot of companies
like gigabyte Asustek and others doesn't
care too much about the security side
because like they small and they just
want to ship product as fast as they can
and it's a lot of like hardware features
came always within new hardware and they
don't have really even like security
validation process for their favors and
also now it's no more release a bias on
new hardware but we have legacy inside
you 5 firmware and let's actually look
inside the firmware update image how
many other firm worst came with a bias
update image so actually just recently
you know like Infineon case with TPM
issue right so and actually TPM updates
sometimes came also with the BIOS update
image and we do have like network
adapters we do have graphics sensors
embedded controller even power
management Oh nowadays actually the
batteries has a firmware to inside your
laptops so mg SMC BMC like a lot of a
lot of different farmers and if like the
door like u5 firmware update is doesn't
have identification or proper update
validation process it's open door I
write for others to break other well
also firmware and it's very interesting
what kind of things we will discuss
today so we will touch a CMS a bit
management engine and mostly focus it on
the boot guard so all the
vulnerabilities which I will discuss in
this talk it's based on my my research
on american megatrends and he'll be
covered some issues from gigabyte ah so
specula nova and msi
so this figure actually shows how many
simple protections like locking bits we
have inside modern hardware from Intel
and some of them is pretty simple it's
just like lock beat for doesn't update
or read spy flash protection Oh spy
flash or we have a bias right protection
bit which is doesn't allow from the
operating system to get in SMM without
disabling this bit which is can be
disabled only from ism by specific
driver and we have a bias walk bit which
is working the bias from the update and
we have fancy technologies like bias
guard and boot guard boot guard actually
armoring the secure boot making root of
trust much more secure and starting
earlier than bias for validation through
the chain of trust and bias guard
actually armoring the updates and both
this technology is working with a CMS
which is actually executed in
identification cache and specifically
for this talk i've been found
i actually found some some
vulnerabilities which is which is
actually pretty simple some of the
vendors just don't use the protection
bids and some of the some of the vendors
don't use the policies for the spy flash
regions for like isolate some of the
regions to be updated or right be
written from from the bios update
process and also some of the vendors
just don't use the sign digital sign for
the updates out gentrification which is
a lot Iker modifies the bios image and
deliver something malicious and some of
the vendors like gigabyte don't use boot
guard properly and it's a lot harder to
actually bypass this technology and i
will introduce one
the first known bypasses for this
technology today so how different
vendors care about the biosecurity and
you can see here like different vendors
some of them focus it on enterprise
market some of them on the game industry
and you can see the difference and also
like a lot of people think like Apple is
a good example of perfect hardware
vendor which is not actually true
because they also don't use all of the
mitigations and as examples they don't
use boot boot guard and they just have a
secure boot which is started after the
BIOS already like passes at a stage
platform initialization stage but I
think it will be improved soon because
they have very strong security team for
you fight farmer and on other side we
have a Dell which has actually been very
responsive for my issues and also like
they don't have it too much and I like
how they protect the BIOS update routine
with uber buzz guard because they do it
a bit different way and it was very hard
to break it so and some of the vendors
it's a screenshot from the tool not
known as a chip sack and we can see like
don't have any of simple protections on
resin actually the screenshot been done
for for seven generation cab you like
from window and the card were being
released in January this year doesn't
have any protections and they just don't
care and specifically on this hardware I
undo akathisia
I make a demo with you if I ran
somewhere it's pretty simple way but
it's show way in visual way how it can
be bypassed so it's already released in
my other talk the details
if if we if we go some specific
exploitation flow so Weiss walk been not
even enabled and attacker is able to
modify bias right protection bead so and
we as attacker we can arbitrary right to
the spy flash chip and make it
persistent from the operating system
level so specifically this demo show as
we have a dog
eggs document which is job some infected
a ufi firmware image on the file system
and then sign a driver from american
megatrends being update using this
update to deliver malicious firmware
without any modifications inside the
driver but I use a privilege escalation
in this driver so and don't verify the
signature and delivers the malicious
update it's not a rocket science and it
shows actually it's possible ways for
remote attacks on a lot of a lot of
different farmers and the main route of
actually also problem not a lot of
people really update the biases even the
companies it's hard right so we have a
zoo from different vendors and different
hardware and it's hard to control how
many hard will have resident update
which is or how many it doesn't have it
so and from a tiger perspective if some
malicious if malware came on the
operating system level which can
actually try to check how the firmware
is up-to-date or check for known issues
and try to actually attack it so how
many people update the buyers in this
room okay
that's good to know how many people not
updated and it's this picture actually
shows the flow how from the operating
system level we can get in spy flash
persistently and think is like we need
of course I don't know memory corruption
or some bug inside browser or flash or
whatever we just came up through there
or spread phishing email visit docx or
PDF then of course we need get into the
kernel mode because without kernel mode
we can't communicate with the SMI
handlers or some services which is
responsible for the BIOS update or
writing to the spy flash so after that
we map it or use a specific application
from the vendor to map the update image
for some specific memory region and
after that we call inside the system
management mode the service which is
actually named it as it's my handler to
get this image read inside this mam and
update the spy flash or it can be
actually done in different way but some
of vendors which I checked doing the
that way so and even if the drivers even
if BIOS update is sign it if any
vulnerabilities inside this is my flash
always is SMI handlers which is if
speaking simply explain it it's like cow
back function from bias to operating
system level for reading and writing the
spy flash and in the past the lot of
them use it just is my flash driver
which is doesn't identification it's
being like a lot of issues there and
after some time some of the vendors
start using security so my flash which
is fully date digital sign for the BIOS
updates and actually I found one issue
on Asus tag with this second semi flash
driver and even if by high net you can
attack sex to my flash to modify the
flow for for for the flash and update
without any sign verification here is a
bit about this my flash issues so this
specific dragger are responsible for
writing reading and like enabling this
kind of function and also it is like
getting some information about how spy
flash how many memories has and how how
actually bios update feed for for this
circuit of my flesh it's a bit more
interesting because it's validate the
update for for for digital sign and it's
voting image and get information about
sign and validate the sign and actually
here is the number of is my handlers
which is can code from the operating
system level and all of them being
vulnerable for simple call out attacks
which is pretty much simple to exploit
and what I did and of course it's why
why is guard been created by Intel and
actually Visegrad guard it's pretty
interesting technology and it's
available on most of the platforms which
is used V Pro so it's a bit about
responsible discs were fun so and you
can see how actually how much time you
need to patch the issues for the bias
even if it will be like one bit change
inside the BIOS code
but most interesting part it's like how
some of the vendors react so I submit
the issues to a stack and after a month
of my email they send me I send it
flower follow-up email and they say okay
it's no issues I said how come actually
I found the issues I send details no no
we push it already so I make a bean dip
of BIOS update and then I see like they
push it exactly my issues a new update
just like few weeks after I send it in
well and after some pressure to a stack
they actually submit me send me another
email where they say okay yeah we
recognize it was your issues and it's
also like shows the level of of the
vendors how they redid to communicate
with researchers and research community
which is actually without any money
tried to help to fix and try to actually
make their products more secure right
it's no bug bounties from us it's like
they just we just given them for free
and if we switch on the mitigation
technology I want to talk about the into
boot guard which is pretty interesting
technology it start with a date root
root of chain of trust from early
beginning even before the bias started
and it's actually very good from the
security perspective but it's also like
always you some of the things come for
the manufacturing and third parties
implementation I mean like hardware
vendors and I Belize and it's where
they're failed but let's talk a bit
about different shades of secure boot a
regional secure boot been introduced on
in 2012
and actually a root of trust been fully
based on the buyers that's mean any
issue inside the system management mode
or not only sometimes can break it root
of trust so or attack surface based on
farmer sir
after some time it's been introduced at
measured boot and verified boot schemes
and measure it Buddha is actually based
on TPM where the root of trust in is TPM
but all the secrets and all the code
implementation stirred inside buyers so
and it's still attack surface will be in
firmer right and only verified boot has
some field program infuse hash value
which is log root of trust inside the
hardware and here is firmware and
hardware attack surface came so let's
talk a bit why boot guard has been
created so classical secure boot can be
starts from the Dixie phase which is
most threatened face just before
firmware plus the control to the
operating system but loaders and it can
be impacted with any SMM issues or like
SMM or bios implant not all of the bios
in points but from with some unbiased
implants definitely and also it was no
verification for early boot stages like
second platform initialization boot
phases from other side measure it boot
starts just before pay face which is
platform installation and can be also
impacted with the same issues and as we
said before the root of trust moved
visibly fight boot to the hardware and
it's how actually into boot guard
protect
in most like stricted mod the chain of
trust and also for foremost strongest
protection verification should rely on
microcode identification as example
microcode is out indicate a CMS for
being executed this picture I copied
from Vincent Zimmer's block and it's
actually first picture which is show
some details about food guard technology
but it's no open specification and it's
actually pretty old picture and I start
actually my research from here and start
figuring out how actually boot guard
flow works and this picture actually
demonstrates some high level overview
how it's started so we have a CPU reset
which is passed control to the CPU
microcode and identification and wrote
from BIOS update image actually ACM
start and BIOS update image and if
identification from micro code files
attacker just can use some malicious or
modified ACMs
and ECM verifies the flow after that and
pass the control to reset vector and IBB
which is initial boot block it's some
hashes values which is very find a
second zap a face and after that just
pass the control to the classical secure
boot and operating system will be loaded
into boot guard technology has a few
different operating modes and most
strongest not its verified boot when the
root of trust as I say lock it in the
hardware and you can also use in the
both mods like measure it boot bruce
verified boot which is most strongest
mode for the intel good guard this
picture i also copied from vincent
Zimmer's blog post
and let's and let's look how actually
policy policy verification works so on
the different phases we have a different
policy and I start figuring out how it
really works so and the start point it's
actually filled program and views after
that we do have like IBB which is
initial boot block and ICM actually
verify IBB and this picture actually
demonstrate in my opinion like real
world picture at least for some of the
bias vendors and I as I say on beginning
i reconstructed american megatrends bias
and this probably looks very close as it
is in standard so and also it's been
extracted by reverse engineering so we
have a que manifest which is store hash
of IBB public key and om root public key
and actually I am route public key is
should be logged by field program infuse
if it is not actually it can be an issue
but it's not enough I will say why a
little bit later on my voice and this
kind of policies stir it inside the BIOS
update image so any attacker has access
to the bios update image it's mean like
he can download from this vendor side
and play it on top of it a bit so only
this part rely on the hardware all this
part actually store inside the firmware
and it's actually this picture
demonstrates the route of trust and this
been specifically released before my
talk on blackhat by Dell and it's most
actually detail it
information about how boot guard works
from some of the vendor which is has
access to the documentation
yeah and it's actually the same thing
but relying on Dell documentation which
is we seen before and I actually checked
different vendors configuration for the
boot guard and buyers guard and we can
see how different it is for different
vendors and some of them using the boot
guard but don't use the BIOS guard which
is actually make BIOS update process
much more unsecure and most actually
worst ones its gigabyte MSI and a so
straggling but also some of the vendors
like Lenovo on some of the platforms
don't use at all the boot guard but so
it's possible because it should cost
some money right for more expensive
systems they do but this kind of systems
I a bit research for my talk so as you
can see trust no-one because if you see
on on some information feature
information on the website they use
something or not it's just say they have
this technology in your hardware but how
properly they use you don't know Willian
and for specifically for preventing
supply chain attacks it's very important
to actually make some validation process
for the hardware before it will be
shipped to the data centers first
information about the boot guard came
from Alex Ermolov on last year zero
night talk and it's interesting because
he found the system from gigabyte which
is
the boot guard but the boot guard not
been enabled and not been actually
configured so if attacker know how
modify this technology in active stage
and then deliver malicious update the
actually attacker can just walk the
route kid inside your firmware and
because that hacker has a private key
for the all the policies and it will be
locked by fueled programming views it's
no way how you can update or extract
this rootkit so it will be locket
forever it just need like what of
probably it's you just provide this to
trash the hardware so it's how it looks
in in config in policies inside
Fito into flash image though and you can
see like boot guard doesn't enable it
and om public hash key is zeros so and
also in this case field programming fuse
not been set up
so that's mean like attacker modifies
the public hash key delivers the
malicious update and lock the fuse so
but here
why would guard not been enabled it's
not bypass it just like Alex use it boot
guard for enabling the boot guard and
show how the rootkit can be locked
inside the platform as a POC but as
somebody on Twitter says you never
attack the standard you always attack oh
yeah you always attack implementation
and I actually get to look inside how
specific platforms works for validate
the bias as a boot guard and
as we can see like came when you first
and it's startin to you Pfeiffer very
much I'll construct some of the field
for from the this structure and we can
see here is a public key and if a tiger
if root of trust not locked in the card
where attacker just can change all the
keys right so modify all the policies if
he knows where stored where what and we
do have IBM cache which is also need to
be change it for for for that hack on
the boot guard but I will discuss all
the flow a bit later also I will
construct initial blog boot manifest it
is here so we have IBB hashes which is
actually validate ii pay phase and i
will be offset which is shows where it
specifically located protected regions
in size if you fi bias so and also we
have a RSA signature which is can be
changed and public key of course - so if
I - some time ago already shows and
parse in the feed boot guard policy and
Kim Yuna first policy and also shows
where the ECM stored so you can easily
extract that it's because in GDK we have
a values for the feed structure which is
shows where where where it's based off
set for for the specific policies and
it's actually how initial boot block
looks like so we have cash value and
offset so and it's example specifically
for this IB B which is the window
covered by these hashes and also if the
vendor make a mistake on the
hovering the BIOS update with IBB hashes
so it can be some window which has been
unprotected an attacker can use it for
modifying that if it will be like
executable code it's like the flow for
delivering some rootkit also interesting
part it's authenticated code model which
is all the ACMs which is i seen before
like it's shivered by intel and it has
some header which is actually pointing
to entry point inside the ACM model and
they say model actually executes since
the hash in the cache and we do have a
digital sign for four for each ACM model
and it's actually will be verified by
micro code
so what kind of things actually what
kind of parameters for for a cm we have
so it's x86 code specifically 32-bit
execute in a serum which is kind of
caches Ram also known as non-addicted
mod and it's all the ACMs it's CPU and
chipset specifics so it's because
microcode willand eight the sign so if
your cpu generation doesn't have
verification for your ACM it will be not
executed and ACM verify the community
and IBM policy I start thinking about
like okay we have executed executable
code inside a CMS and I will construct
some some format and build some loader
simple loader for Friday but most
interesting thing it's like how if we
bend Eve different generation of of a
CMS actually a CMS for different
generation of CPUs how it will be looks
like for one technology like a boot
guard right so and actually ACM code
it's pretty complex we have a flow even
like we have some cryptic verifications
there for sha-256 era say and it's
everything is there right so and it's
pretty complex technologies so its flow
from a sim but most interesting part
it's I make some bean dip with different
different generation of CPUs so has both
where's the sky wake and I doesn't found
too much here I don't know maybe I've
been just unlucky but I found the really
small change but when I
did some bindi fees broad well where's
the sky wake I found like a lot of
changes and this changes show me like
this kind of parcels has a lot of issues
like some of them integer overflows some
of them really like mistakes in the code
or whatever but it's a lot of patches
being there so and let's talk a bit how
how many components bias Guard has
incites bias so we do have a platform
initialization model model like boot
guard pay SMA which is actually verify
firmware boot guard from ISM I am when
it will be like not fully rebooted the
Carter will be not fully rebooted and
it's just like warm aggressive and Dixie
which is verify the boot guard for from
s3 sleep mode here is a flow for the pay
validation and we can see here actually
in this flow its calculate the hash and
it stores the hash but we also have a
flock which is 0 or 1 in specific case
and it shows it's really dated or not
and it's passing to good guard dixie
driver so and it's actually will a date
pay firmware hash which is covered of
the firmware in my case and what happens
actually how how we fight would guard
from Assam and validation flow works
it's fine and verify ACM and verify all
the keys I will be a bit speed up
because I have just seven minutes I
think so most interesting thing can this
wide as I say it said flag for 0 to 1
true or false
when the validation is right and
here is actually yeah I chose this issue
on on blackhat now it's a rigid fix it
on mostly on all the vendors and it's
been fun because some of the vendors
from like huge enterprises came to me
and say oh we just recently patch it and
I don't have a time to really like
follow all process to discuss this issue
and its small back actually and think is
this logical back opens the door when
you have like a story set to put some
malicious components are caught inside
your buyers and boot guard wheel doesn't
help here and actually embedded as a
company recently based on top of my
research released same thing to Intel
knock and it's a really budget and they
do have some blog post which is a bit
provide more detail about how they
exploited here is my target platform and
its sixth generation Quran skylake bias
guard is enabled and boot boot guard is
enabled by as guard is not here is
vulnerabilities both as we can see it's
for bypassing the boot guards need to
vulnerabilities first its write read
access to me and second one as a
configuration for the boot guard is not
locked why we need a vulnerability for a
me because we need to lock the fuse and
the fuse can be locked only from email
so here is the details from intoa me
tool so on this platform as we can see
if PF doesn't set but the public key for
from I am is is in a place and we fight
boot and measured boot is enabled but
also we can see like a me region has
access for read and write so here is
shows way
we have most strong mode for boot guard
enabled and funny fact from gigabyte
official website they proposed this card
work for like governmental for critical
infrastructure for hospitals but don't
care too much about the security and
here is a flow which is shows how the
boot guard can be bypassed so we
actually because we control every all
the structures or the policies inside
the firmware we just modify all the
things like and that's it and if it's
not locked in the hardware so we just
actually can bypass all the boot guard
policies so here is the intel statement
and intel says like third-party SI
babies should actually lock the boot
guard root of trust inside the hardware
and and it's probably written in the
specification too so it's gigabyte
statement which is say like they release
its update what the update should be
separately from the bios update download
from the website of vendor and installed
and i don't know how many users will do
that right this month actually last
month i developed you fi to update for
into a boot guard visual verification
and it shows specifically how many
firmware volumes and what kind of
drivers is covered here is a blog post
here is a link to the tool and
specifically for blue heart this sunday
I push the update for you if I to in now
it supports surface laptops to and
actually I've been surprised and on
surface they did a bit in-house
implementation of into boot guard
technology and it's much better than
others we under not all of the others
but a lot of so here is a link on my
blog cut research and actually I will be
update
after zero nights with all the my
templates 4:01 editor and all the
scripts for item thank you very much for
your attention and if you have any
questions I will be happy to answer and
I hope you have the time yeah we do have
three minutes okay microphone runners
will be ready to take your questions
make them interesting
I I noticed that you mentioned that only
some of the regions of buyers are
protected behind the RSA signatures why
why not sign the entire image instead so
they sign so actually not like that
the signature protect I BB which is
contains the hashes and as you can see
like hashes is sign it and you can't
modify the hashes and hashes actually
covered all the buyers usually what it
is cannot so what what is the reason for
for like even even allowing mechanism
make more flexible the technology for
third parties so so that they don't have
to go through hassles of signing every
release of bias or as examples they can
sign different pieces of the image
different way as example or one vendor
control sign of one piece and another
from another piece of image thank you I
don't know it's my opinion but I'm not a
hardware developer manufacturer and
actually technology's undocumented is
just gas I can be wrong
no more questions just a simple one
when's the book gonna be completed
when's the book gonna be ready good the
book Oh actually we made some early
release for the DEF CON and it's been
sold out so all the book it's already
ready early access will be updated this
month for all the chapters and printed
in January sorry have you guys
considered including anything about
grayish we don't have so we already
extend like a lot of chapters for the
bias and we have a pressure from
publisher to not add anything more so
probably next book will be like open
wiki book because it will be easier to
add more and more contact and don't have
logistics with publisher right so in a
perfect world if you got to decide
exactly how the disclosure process went
with the vendors what would be your a
perfect version you know like it's
difficult because perfect world for the
vendor it's one world perfect world for
researcher I I am both side side right
so it's difficult actually I think like
at least I expect some collaboration
from the vendor side because like if you
send something then like send follow-up
email and the vendor like reply no box
but then release its update silently
with your box budget it's a bad way
right so here is like some should be
best practices exist right for that like
be polite with researcher and the
searcher will be polite view people head
with the vendor
so because like in the u5 world it's not
a lot of bug bounties actually intel
offer one but it's covered on these
their products and their CPUs it's also
included the hardware box for u5
firmware it's just for Xanax NC servers
so it's not a lot
so probably Microsoft will be introduced
some bug bounty for surface I don't know
thank you one more question here
just out of curiosity you mentioned that
vendors have a lot like obviously have
bugs and then he asked us who updated
our bias recently so the question is
just again out of curiosity is there any
common techniques or procedures to
basically push the pressure on customer
to update bias or how it's done in
hardware you can't push the customer
site and what you apply you update your
bias or none okay I'm kidding
so actually it's no pressure to to
customers because it's like okay
probably if updates as example for
Windows software will be delivered by
Windows Update process it will be
perfect world but it's like this perfect
world will be never happens because we
need from the vendor they should prepare
the update for specific time frame right
to be delivered and also it should be
like unified process to update the
systems and this also will be never
happens because all the vendors have
some house features which is very
specific for us rail hardware so and I
don't know actually for the big
companies it's important and
specifically also for the data centers
it's important to probably have some
process at least make some health checks
for their Hardware of biases what I
think but it's basically like you know
on customer itself no no unified
solution here and it will be never
happen sexually what I think okay so
unfortunately we do have to end
questions for Alex because we have the
next set
so round of applause for Alex thank you
very much
you