
Report on the technical vulnerabilities found in Huawei 5G [pdf] - UkiahSmith
https://finitestate.io/wp-content/uploads/2019/06/Finite-State-SCA1-Final.pdf
======
Noxmiles
"On dozens of occasions, Huawei engineers disguised known unsafe functions
(such as memcpy) as the “safe” version (memcpy_s) by creating wrapper
functions with the “safe” name but none of the safety checks. This leads to
thousands of vulnerable conditions in their code."

Things like this everywhere. Just stupid programmers or method?

~~~
AnimalMuppet
To actually _fix_ this, you have to call memcpy_s instead of memcpy, and then
_not_ create the wrapper, which seems like almost the same amount of work, but
slightly less. So why create the wrapper? Their library didn't have a memcpy_s
function?

~~~
rurban
Huawei is actually one of the very few vendors which do provide the Annex K
functions. I can only name Cisco, Intel, Embarcadero, HP and Microsoft who
also do so. But Intel very badly.

The report is right to call out Huawei engineers to bypass these checks. They
probably had the same attitude to bounds checks as all open source developers
and industry practioners.

------
heisenbit
It seems odd to have a report with a 5G label and then find information in it
about core routers. Yes they play a part but it strikes me as odd that there
is no focus on mobile switching, gateways, HLRs, signaling vulnerabilites
etc..

When looking at the boxes they compare:

Huawei: CloudEngine 12800 scales up to 2000 * 25GBit or 500 * 40GBit Juniper:
EX4650 Ethernet Switch scales up 48*25GBit

With all due respect but this is comparing apples with orange seeds. A carrier
class switch is more complex than an enterprise switch and has a much larger
attack surface.

~~~
bifrost
Its probably a shared codebase, I wouldn't be surprised if they had a
monolithic OS and just had specific daemons to run things.

~~~
october_sky
Shared codebase + more offload ASIC processors is exactly what I'd expect

~~~
bifrost
Exactly.

Most network forwarding happens on ASICs, its the only reasonable way to get
performance.

------
joshgel
> While we cannot prove malicious intent through a technical analysis, we can
> concretely state that 55% of tested devices had at least one potential
> backdoor

~~~
svdr
And: "In virtually all categories we examined, Huawei devices were found to be
less secure than those from other vendors making similar devices."

~~~
djsumdog
I was wondering about how bad this was against industrial standards,
considering they've been articles about TP-Link and other Internet-of-Trash
devices that have a lot of unpatched issues.

The article seems to suggest Hawaii is exceptionally bad at patching or best
practices in security.

~~~
rossdavidh
It's a low bar, but apparently they managed to not clear it.

------
dade_
Not since the days of Microsoft astro-turfing have I seen such a campaign
against a tech company. Some of these metrics are very subjective and I've
seen so many bone-headed security bugs in equipment over the years (Cisco,
Nortel, TP link, Dlink...) that I really have difficulty believing the
narrative of state sponsored malice.

Regardless, Huawei needs to clean up their practices. Ineptitude isn't a
defense and this level of sloppiness is unacceptable; We have too much at
stake with these essential networks, and I think legislation of security
practices and standards in these products should be considered.

~~~
robocat
> Regardless, Huawei needs to clean up their practices.

Sure. So does every crappy home router manufacturer, Android manufacturer,
security cam manufacturer etc: singling out Huawei is retarded.

Personally I suspect that biggest issue is that the US doesn't wish to lose
their own NSA phone/txt backdoor access (thumbs in everyone's pies). They have
access to most US TCP/IP traffic, so they don't need to target router
manufacturers.

~~~
dade_
Yes, but this is actually an opportunity for Huawei. If I was them, I would
take these findings and hire a team of hackers/sec researches to rip their
products apart, fix the issues and then put then up for independent comparison
with competitors. They have all of the resources one could dream if to be the
best for security. It would be nice if anyone would set a high bar.

------
Shank
Some of these items seem like they need more analysis, and that the report was
rushed. We agree as a community that hard coded default passwords are bad when
unchanged, but that implies that the device doesn't require them to be changed
on first boot. Basic setup processes often require these credentials to change
after the first provision.

I would expect a report which produces claims about such comprehensive
backdooring and negligence to at least demonstrate how that behavior would
play out in the real world. It seems much more like they did static analysis
of the binaries, identified any strings with default passwords, and then
reported on them. That's okay to do, but you can't conclude that's a problem
until you confirm shoddy behavior after provisioning and deployment in
practice.

------
TedTschopp
The process and practice findings are the most damning in my opinion. This
isn't a opps we were rushing to market, this is a problem with values and in
my mind damns the whole organization.

~~~
djsumdog
Basic security tooling to remove hard coded keys of any kind need to be in the
process. I bet shops like Cisco/Linksys, Neatgear and others at least make
some attempt of this in their CI process.

~~~
rndgermandude
No

[https://nvd.nist.gov/vuln/detail/CVE-2019-1804](https://nvd.nist.gov/vuln/detail/CVE-2019-1804)

------
ru999gol
The huawei user account hardcoded in the firmware that has sudoers permissions
for insmod/modprobe is really blatant. I would have guessed the Chinese would
at least attempt to hide their way in?

So they sell enterprise infrastructure equipment with such an obvious
backdoor? It seems the US boycott of Huawei was fully justified after all, I
didn't really believe them.

~~~
bennofs
That doesn't have to be a backdoor. Remember the wave of bugs caused by
hardcoded secrets in Cisco hardware?

Might just be some leftover debugging account or for service.

~~~
ABCLAW
>That doesn't have to be a backdoor.

It is a backdoor. The definition of the term doesn't require intent.

------
majia
The report says that Huawei devices have unsafe functions like “memcpy” and
"strcpy". Is this a coding preference or dangerous practice? To what extent
can these examples reflect on code quality?

~~~
ploxiln
strcpy() - sure it is fairly often used unsafely, strlcpy() or snprintf() or
similar should generally be used. But memcpy()? It takes an explicit length,
which you have to calculate. What's the alternative? memcpy_s() does part of
the check for you, but you end up writing more code around it. It's trying too
hard and not achieving a net positive. I have seen "use of unsafe function
memcpy()" show up in some dumb security scans recently, and it's a strange
development. There is lots of C code where avoiding memcpy() would be quite
awkward and really not help anything at all, it's just a fundamental
operation.

Here's a dry technical report on how the new-ish _s variants are not really
helpful: [http://www.open-
std.org/jtc1/sc22/wg14/www/docs/n1967.htm](http://www.open-
std.org/jtc1/sc22/wg14/www/docs/n1967.htm)

~~~
rurban
This technical report is nonsensical, and asks for continuation of widespread
insecure practices. The authors (the glibc maintainer) should be removed from
the committee for spreading such harm. He simply doesn't like secure
practices, and continue to use sometimes checked calls. If he would have some
technical competence he would implement the needed safety checks seperated
into compile-time (no performance penalty) and runtime (when the compiler
doesn't know). He only does the first, and leaves all the dynamic cases
unchecked. But then he would stumble over the inability of gcc to properly
handle compile-time expressions.

See eg.
[https://rurban.github.io/safeclib/doc/safec-3.5/index.html](https://rurban.github.io/safeclib/doc/safec-3.5/index.html)

------
bifrost
I'm so glad this isn't about how "5G is dangerous zomg".

We're lucky to get this sort of report!

(In case you were looking for an article about the safety of 5G ->
[https://medium.com/@tomsparks/is-5g-dangerous-405a19e9ea88](https://medium.com/@tomsparks/is-5g-dangerous-405a19e9ea88))

------
elmo2you
It's hard to say to which extend this "assessment" is honestly backed by solid
evidence, or if it was written first and foremost for political reasons. The
broad claims, apparent lack of factual evidence (only statements about what
has been discovered), and rather overarching nature of the whole report, sure
do suggest it could be the latter. Pure speculation on my own part, of course.

I have not gone through the full report (yet), but while reading just a few
sections my sales-pitch-bullshit-meter went on full tilt, at least a few
times.

The timing of this report is also peculiar, to say the least. Who is Finite
State? What is their track record, to date? Who owns the company? What
business relationships/interests do the company and its owners have?

Yes, I realize/know these are suggestive questions. Questions that should
nonetheless have satisfying/assuring answers, in order take this report
seriously.

There's a lot at stake here, so at least examining the validity of this
report/summary isn't just a luxury.

Are the factual findings behind this report publicly available?

~~~
gtirloni
They did it using their analysis automation software (iotasphere) and the list
of devices is in appendix A.

Someone knowledgeable about forensics with access to the same devices probably
can validate those claims.

~~~
elmo2you
I sure hope that someone will. I do not have access these devices, neither do
I have any inclination to buying their commercial product in order to verify
their claims.

Maybe their product is brilliant, and/or maybe they did a lot of manual
verification of their automated scans, in which case their report could be
accurate (though still hard to verify).

That said, my experience with both static analysis and runtime security
scanner is less than stellar. They are without a doubt useful tools, if not
indispensable. But they usually generate more leads for further (manual)
analyses, rather than generate (accurate) final verdicts.

Granted that pen-testing is a different animal (but one I have more experience
with), I often have had to explain to customers that the reports they got from
security auditing companies were full of false conclusion. More often than not
because those companies were relying/trusting too much on automatically
generated results, in addition to them trying to sell additional services. So,
forgive me if I'm skeptical.

That Finite State apparently has a stake of their own here (promotion of their
product), which makes me only less inclined towards giving them the benefit of
a doubt.

As I mentioned before, this is of course all speculation on my part. Still,
until Finite State publishes their factual/detailed scan results, I believe I
have every reason to consider that this might be either a political motivated
report, or more likely be an attempt to use/abuse the current political
climate to promote their own product and services.

------
Kenji
_• 29% of all devices tested had at least one default username and password
stored in the firmware, enabling access to the device if administrators don’t
change these credentials.

• We identified 76 instances of firmware where the device was, by default,
configured such that a root user with a hard-coded password could log in over
the SSH protocol, providing for default backdoor access.

• 8 different firmware images were found to have pre-computed authorized_keys
hard coded into the firmware, enabling backdoor access to the holder of the
private key.

• 424 different firmware images contained hardcoded private SSH keys, which
can enable a man-in-the-middle to manipulate and/or decrypt traffic going to
the device._

What a witch hunt... This is state of the art in the industry. Everybody does
it like that. No intelligence agency has to be involved at all, it's basic
negligence. If you're behind a NAT, your device is unlikely to be attacked via
these vectors.

~~~
WordyMcWordface
Exactly, every vendor has default passwords. If you are doing things right all
default credentials are changed or disabled. Access to any service is
firewalled off or better yet only accessible out of band on a dedicated
management network.

~~~
djsumdog
This is changing. I've seen a number of ISPs no longer have default passwords.
Each router or modem has a random password string set to the device, it's
printed out and pasted as a sticker on the modem (or some print directly to
the plastic). A lot of big name devices do this now too.

Sure it's a password written on the device, but it's random, you need physical
access to see it, and people who are security conscious can change it.

This bad practice isn't excusable, especially not by a company as big as
Huawai, not if they want to be taken seriously.

~~~
elmo2you
It's definitely a good development that ISPs have started to deploy routers
and modems with randomized passwords. However, please do keep in mind the
deployment of consumer equipment and enterprise hardware is different. Or at
least it should be, in theory.

Enterprise equipment is usually not supposed to be just dropped into place,
without oversight. It usually needs proper configuration/management, by
qualified people.

Whether this also happens in practice can be a different story altogether.
Still, the security of enterprise equipment usually involves more policy and
procedure than it does with consumer equipment. With the latter, security has
to come more or less by default, because the people handling the devices
usually have little expert knowledge.

------
ngcc_hk
It is not the bug now but bug in the future. It is whether you can trust a
country that respect nothing human.

Can you even a campaign against anything once they take over your information
infrastructure.

Yes NSA may do it but cf NSA with PLA ... what is your leverage. Hear of the
word totalitarian...

