[Cryptography] UK "HCSEC" UK-cleared engineers try to prove Huawei gear secure

John Gilmore gnu at toad.com
Thu Feb 20 04:46:31 EST 2020


A recent inflammatory Washington Examiner article pointed me at this
report:

  https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/790270/HCSEC_OversightBoardReport-2019.pdf

which details the UK "National Cyber Security Center" (formerly known as
GCHQ, i.e. the UK's NSA) successful effort to build a 50-person team of
classified spooks with full access to Huawei source code.  They are
attempting to test the assertion that all the Huawei products sold in
the UK are secure.

As expectable, they are finding plenty of typical industry-wide security
issues.

They fault Huawei's software development process for failing to provide
reproducible binaries.  The oversight board claims "the end-to-end
assurance that a particular source code set is precisely that used to
build a particular binary would normally be satisfied as a side effect
of a modern software engineering process."  That's a good theory, though
it's unfair to apply it only to Huawei, since it appears to me that it
is so far seldom achieved in practice in real operating system or
firmware development.  See for example the Reproducible Builds project
which is attempting to approach this for major free software operating
systems: https://reproducible-builds.org/ and has not fully succeeded
with any of them.  (Cygnus Support achieved sustained reproducible
builds and cross-builds of its GNU software development tool releases in
the mid-1990s, but this effort covers a much more extensive set of
software.)

The report also says that their team has found hundreds of security issues
in the Huawei products (such as LTE routers), including:

  unprotected stack overflows in publicly accessible protocols, protocol
  robustness errors leading to denial of service, logic errors,
  cryptographic weaknesses, default credentials and many other basic
  vulnerability types.

Since the team is operating under UK classification rules, the details
of these vulnerabilities probably haven't been reported to anybody but
the UK spooks (for exploitation, of course) and their NSA friends.  It's
not clear whether Huawei has been told, or whether any end-users of
Huawei equipment have been told, what these vulnerabilities are.

The report also concludes that:

  These findings are about basic engineering competence and cyber
  security hygiene that give rise to vulnerabilities that are capable of
  being exploited by a range of actors. NCSC does not believe that the
  defects identified are a result of Chinese state interference.

There's a further issue that all of Huawei's products are based on:

  various old and soon-to-be out of mainstream support versions of a
  widely used [unidentified] third-party real time operating system,
  which Huawei has chosen to continue to use within products whose end
  of life date is significantly longer.  ...  Furthermore, the operating
  system in question is based on a single memory space, single user
  model (as was prevalent at its time of design), which further
  increases risk as a single vulnerability in any process running under
  this operating system is sufficient to allow compromise of any
  component running in the same operating system instance.

  ...  Huawei’s intent [is] to move off the operating system that is
  soon-to-be out of mainline support to their own real time operating
  system, based on the open source Linux kernel.

In checking a few sub-components in particular, they ran into other issues
with "component and lifecycle management":

  NCSC then selected a commonly used component, the OpenSSL library, and
  specific queries were performed on the Huawei development
  database. This showed that there were an unmanageable number of
  versions of OpenSSL permitted to be used in products, including
  versions that are not on the main development train, that have known
  vulnerabilities and that are unsupported.   ...

  In the first version of the software, there were 70 full copies of 4
  different OpenSSL versions, ranging from 0.9.8 to 1.0.2k (including
  one from a vendor SDK) with partial copies of 14 versions, ranging
  from 0.9.7d to 1.0.2k, those partial copies numbering 304. Fragments
  of 10 versions, ranging from 0.9.6 to 1.0.2k, were also found across
  the codebase, with these normally being small sets of files that had
  been copied to import some particular functionality. There were also a
  large number of files, again spread across the codebase, that had
  started life in the OpenSSL library and had been modified by Huawei.

  In the later version, there were only 6 copies of 2 different OpenSSL
  versions, with 5 being 1.0.2k and one fork from a vendor SDK. There
  remained 17 partial copies of 3 versions, ranging from 0.9.7d to
  1.0.2k. The fragments from the 10 different versions of OpenSSL
  remained across the codebase as do the OpenSSL derived files that have
  been modified by Huawei. More worryingly, the later version appears to
  contain code that is vulnerable to 10 publicly disclosed OpenSSL
  vulnerabilities, some dating back to 2006.

It's an interesting document, though you have to wade through some 46
pages to find the fun bits.  Overall, the effort looks like a win/win,
in that the UK gets a much more detailed, bigger clue about the actual
security of Huawei gear (both in the UK and worldwide), and Huawei gets
a world-class team beating on every aspect of their software development
and configuration control process and their code, all the way down to
looking for (and finding) sprintf's that should be snprintf's.

	John
	


More information about the cryptography mailing list