Huawei savaged by Brit code review board over pisspoor dev practices

Re: Real point here

My thoughts exactly

Re: Real point here

And what do you do when nobody does particularly well? You still need critical infrastructure, but it seems like all the players are a bit Swiss-cheese

Re: Real point here

Actually you do.

Ever heard of Common Criteria or NIAP?

Look at host which have been tested to EAL4+, and then read the report to find out how each did during the test. Just having the certification isn't enough, you should read the report as well.

So where are all of the Euro-Brats who thought the USA and a few other countries thought were Bat-s-Crazy for bringing this up? Now, England will spend a fortune, because they refused to do research when they were first warned.

Don't worry... China will still trade with you, they have no choice.

Re: Real point here

Funny you should mention Cisco. Just recently this flew past...

https://twitter.com/RedTeamPT/status/1110843396657238016

Too lazy to click link? The nutshell: Cisco had a remote code execution issue in their Small Biz Router line. The PoC made use of curl. The Cisco "patch" blacklisted the curl User-Agent. Let that sink in.

Re: Real point here

So does the fact that Huawei has had this free code review mean it's now been given a competitive advantage?

Re: Real point here

I can't fail to notice that Apple and Samsung, beloved tech corps of the USA govt, have taken an utter pounding this year by Huawei (Apple's share value dropped by several hundred billion dollars recently, with huge market sharegoing to Huawei).

For one, while Apple is plugging £1000 bland unexciting phones, Samsung preloads (and bans the deletion) of epic bloatware, Huawei stuck to a headphone jack and sold a £200 smartphone without bloatware, that even included a revolutionary technology called the 'headphone jack' (while Apple and Samsung push £200 wireless headphones, ick).

So alas, I, for one take American criticism with an ounce of salt.

Re: Real point here

This should be standard procedure for all secure government installations when dealing with vendors, both foreign and domestic.

here's REAL malware

https://shadowhammer.kaspersky.com/

a targeted attack on a million ASUS's , signed using a 'real' ASUS certificate, downloaded from the real ASUS website, sniffs a lot of a Nation State APT attack who's parliament now permits illegal acts for NatSec.

meanwhile, according to https://www.asiatimes.com/2019/03/article/the-eu-bows-to-systemic-rival-china/

all of this digital protectionism is too little, too late. get over it.

Re: Real point here

I was hoping to see a comparative study to Cisco. My company gives Cisco over a billion Euro a year and while this seems damning to Huawei, I am the pretty sure Cisco is as bad.

1) Multiple OpenSSL instances is normal. They should however be pulled from the same repositories. There are good reasons to compile OpenSSL differently based on context. I compile it differently when using it in kernel space or in user space. OpenSSL is an absolute must for security... this is because OpenSSL is the absolute most hacked library EVER because of mass economy. But that also means it should be the fastest patched.

2) Large amount of C code in a network product unless it’s the forwarding engine itself is a really bad idea. Even then, companies like Ericsson code large amount of their systems in Erlang. While I’m no fan of Erlang, it has many benefits over C with regards to this. As such, it would make sense choose Ericsson over Huawei for 5G. Cisco uses C VERY heavily and if you were to look at much of the code Cisco has made public... let’s say they have pretty bad practices.

3) Poorly mapped safe-C type functions for string management. If you’re using C and safe in the same sentence... just don’t. Even the absolute best C code will almost certainly degrade over time. A common pattern which has grown over time in C circles is to make insane messes of goto statements for reallocating objects in the “right order” at the end of functions. I have seen many cases where this degraded over time.

4) 3rd party real-time operating systems are common. If you’re developing network hardware, RTOS makes a lot of sense as opposed to Linux. One reason is because network hardware should have deterministic latency to support protocols like ATM, SDH, ISDN, T1/E1. Vxworks, QNX, GreenHills all made excellent operating systems for communication grade equipment. Most of these systems however suffer from age. SYSBIOS from TI is also great. An excellent aspect of RTOS systems often is the ability to partition the CPU based not only on time share, but also cores.

I honestly think this review might be the best thing to ever happen to Huawei. It is a roadmap to let them plan their next steps. They should really consider looking into using Redox as a foundation to something new. If they invest in building a RTOS scheduler, it could be something glorious... especially for Huawei.

Re: Real point here

Speaking as someone who has worked for another far-eastern-based telecoms equipment supplier (and quit in exasperation), Huwaei sound like paragons of virtu in comparison. As the guy says, we really ought ot be subjecting *everyone* to this level of scrutiny.

Re: Seems a little prejudiced

There's this one because ZOMFG Chinese backdoors. As hinted in the article, and remarked above by somebody else, a general code review for all critical infrastructure would be a good idea. Likely, similar issues will be uncovered in most other equipment.

And IMNSVHO: whoever wrote that code snippet should be [redacted because it's a family friendly site]

Re: Seems a little prejudiced

Because it was set up specifically to address the oversight of Huawei

And if it was the 5G oversight board, we probably wouldn't see it for another two years featuring anyone but Huawei.

Re: The biggest threats to security

you omitted ineptitude...

Re: The biggest threats to security

Fear.

Re: I'm looking at the list of sins...

So this is conclusive proof that Huawei have been spying on British and American workers.

Once GCHQ discovers that the entire platform has been knocked up in PHP scrapped from Stackoverflow by an Indian outsourcer we will know that they have penetrated to the heart of our military-industrial complex

Re: Isn't there some vague idea of mixing suppliers anyway ?

Nobody really mixes suppliers because nobody wants to spend for training (HA!) on more than one set of kit.

Re: One wonders...

If it had been really secure the complaint might have been that it's so secure that they couldn't do a proper review - and thus were unable to determine if the company had implemented any back doors (although the jury is still out on those, apparently).

No, Huawei are really crappy at security and thus make people worried. That's why we should start doing this level of code review for other suppliers as well. Just because it is possible (and likely, I admit that) that other suppliers did the same kind of thing doesn't mean Huawei is great. Without that review, you cannot make a statement like "not noticeably crappier than many other suppliers", just like you couldn't make the statement "infinitely worse than all other mainstream suppliers". You lack the evidence, and have made a completely unfounded statement. In parallel, there are still concerns about links to Chinese intelligence, which this review has not concerned. The code review has not announced the existence of these threats, nor has it announced the completion of the search.

Re: ...memory constraints... ...70 full copies of 4 different OpenSSL versions...

Come to think of it I can see this being turned on incrementally. Critical outward facing modules first running the checked version (turned on by another #define). I remember a system refused to boot after we turned on stack protection ... I guess we had, unknowingly, been corrupting parts of the stack for a long time. It was a brutal fight to get the developers to go find and fix the issues.

Re: ...memory constraints... ...70 full copies of 4 different OpenSSL versions...

Funniest thing is, if they only wrote

<pre>

#define SAFE_LIBRARY_memcpy(dest, destMax, src, count) memcpy(dest, src, (destMax) < (count) ? (destMax) : (count))

</pre>

Then they'd be at least immune to piss-poor stack overflow attacks, even if using plain libc.

Re: Security is not a part of the of organization's KPI

The problem with the Chinese is that they're likely to take this away, go back to their burrows and turn up in a year or two with everything fixed. This isn't the first time we've seen slapdash coding but given the importance of the code and the resources that can be brought to bear on the problem of fixing it they are quite likely to do just that.

So then we'll end up with a whole bunch of competing kit that we'll smugly assume is OK. It won't be, of course, but by the time we discover we've unleashed a formidable competitor it will be very late in the development cycle to do much about it.

"Presumably this is an RTOS that doesn’t have dynamic libraries?"

It's Wind River Linux.

Re: A good thing?

I don't doubt they're all as bad as each other for a second.

Would be interesting if code from other devices was audited too.

Say maybe, the software on an aeroplane.

Re: I’ve not done C in a long time...

Yes.

Re: And as for economic warfare...

but because they're cheaper than Cisco.

+1

Too much respect

The UK is just another catamite of the US.

FTFY.

Re: Boeing 737 Max Audit

Their conclusion would be that the North Koreans / Iranians hacked the software.

:/

You don't need explicit backdoors when the code is that bad.

Re: Funtionality

And speed and cost efficiency trump functionality (and security):

"Does it compile?"

"Yes."

"Well then, ship it!"

Re: Can someone please explain what all the fuss is about.

"Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench".

- Gene Spafford