Dell, HP, and Lenovo Devices Found Using Outdated OpenSSL Versions

An
analysis
of
firmware
images
across
devices
from
Dell,
HP,
and
Lenovo
has
revealed
the
presence
of
outdated
versions
of
the

OpenSSL

cryptographic
library,
underscoring
a
supply
chain
risk.

EFI
Development
Kit,
aka

EDK
,
is
an
open
source
implementation
of
the
Unified
Extensible
Firmware
Interface
(UEFI),
which
functions
as
an
interface
between
the
operating
system
and
the
firmware
embedded
in
the
device’s
hardware.

The
firmware
development
environment,
which
is
in
its
second
iteration
(EDK
II),
comes
with
its
own
cryptographic
package
called

CryptoPkg

that,
in
turn,
makes
use
of
services
from
the
OpenSSL
project.

Per
firmware
security
company
Binarly,
the
firmware
image
associated
with
Lenovo
Thinkpad
enterprise
devices
was
found
to
use
three
different
versions
of
OpenSSL:
0.9.8zb,
1.0.0a,
and
1.0.2j,
the
last
of
which
was
released
in
2018.

What’s
more,
one
of
the
firmware
modules
named
InfineonTpmUpdateDxe
relied
on
OpenSSL
version
0.9.8zb
that
was
shipped
on
August
4,
2014.

“The
InfineonTpmUpdateDxe
module
is
responsible
for
updating
the
firmware
of
Trusted
Platform
Module
(TPM)
on
the
Infineon
chip,”
Binarly

explained

in
a
technical
write-up
last
week.

“This
clearly
indicates
the
supply
chain
problem
with
third-party
dependencies
when
it
looks
like
these
dependencies
never
received
an
update,
even
for
critical
security
issues.”

The
diversity
of
OpenSSL
versions
aside,
some
of
the
firmware
packages
from
Lenovo
and
Dell
utilized
an
even
older
version
(0.9.8l),
which
came
out
on
November
5,
2009.
HP’s
firmware
code,
likewise,
used
a
10-year-old
version
of
the
library
(0.9.8w).

The
fact
that
the
device
firmware
uses
multiple
versions
of
OpenSSL
in
the
same
binary
package
highlights
how
third-party
code
dependencies
can
introduce
more
complexities
in
the
supply
chain
ecosystem.

Binarly
further
pointed
out
the
weaknesses
in
what’s
called
a
Software
Bill
of
Materials
(SBOM)
that
arises
as
a
result
of
integrating
compiled
binary
modules
(aka
closed
source)
in
the
firmware.

“We
see
an
urgent
need
for
an
extra
layer
of
SBOM
Validation
when
it
comes
to
compiled
code
to
validate
on
the
binary
level,
the
list
of
third-party
dependency
information
that
matches
the
actual
SBOM
provided
by
the
vendor,”
the
company
said.

“A ‘trust-but-verify’
approach
is
the
best
way
to
deal
with
SBOM
failures
and
reduce
supply
chain
risks.”

Leave a Reply

Your email address will not be published. Required fields are marked *