randomhacker123

قبل 3 سنواتdiscuss

Sadly this looks like "industry standard" to me. I have seen many embedded Linux devices using mostly C applications and a lot of usage of the system() function with no or very poor input validation before. When you want to exploit embedded Linux devices always look for calls to system() first.

The "strncmp(saved_pwd,pass0,strlen(pass0))" looks equally bad. Probably someone did not understood the advice "always check the length first" and just did it everywhere.

Intel AMT checked the password in a similar way some time ago: https://www.tenable.com/blog/rediscovering-the-intel-amt-vul...

randomhacker123

قبل 5 سنواتdiscuss

Candela Technologies for example has access to the QCA wifi firmware source code for the QCA Wifi 5 AP chips. They provide custom builds here: https://www.candelatech.com/ath10k.php I know of one other company. I do not know if they also have access to the driver source code, but I assume so.

Silicon vendors often do not care about small customers, small is probably less than 250k units per year. If you are a customer which is expected to generate more than 5% of the revenue for the complete product line or the business unit then you get good support from these companies.

The proprietary Broadcom Wifi driver was leaked multiple times by some companies which did not run the script to clean a GPL tar, but did something on their own and forgot to remove the Boardcom wifi driver source code. Last time I saw this was already 8 years ago. The Broadcom proprietary Wifi driver also contained the source code of the firmware running on the ARM chip inside the Wifi IP, at least it did this some time ago.

For the Qualcomm 5G modem and the graphics driver this is probably different.

randomhacker123

قبل 5 سنواتdiscuss

The MediaTek wifi AX platform is supported by OpenWrt master and also supported by upstream Linux including AX wifi. (MediaTek contributes a lot to upstream kernel)

  * MT7622 SoC (2x Cortex-A53, including 4x4 ieee80211n wifi integrated in MT7622 and supported by upstream kernel too)
  * MT7915 Wifi 6 (ieee80211ax) 4x4
  * MT7530 5 port 1G switch (2.5G uplink)

You can find this hardware in the following devices:

  * Linksys E8450 / Belkin RT3200 (same device just different name and color of casing)
  * Ubiquiti UniFi 6 LR
  * Also some others

See here the open source wifi driver for MT7915: https://github.com/torvalds/linux/tree/master/drivers/net/wi...

randomhacker123

قبل 5 سنواتdiscuss

It is very likely that most Qualcomm customers like Starlink have access to the source code of the Qualcomm proprietary Wifi driver for the QCA wifi Access point SoCs. Some vendors also have access to the source code of the proprietary Wifi firmware running on the Tensilica CPUs inside the Wifi IP core of the SoC. (Linux runs on an ARM CPU in this SoC, the wifi IP cores are an extra realtime FW)

End consumers normally do not have access to some source code or any documentation about these chips, sometimes even the competitors are getting access to source code to integrate their solution better. I do not know whom they protect against, probably all people who did not sign a NDA.

These thinks are only shipped to end customers in binary only version to protect the IP from someone. Often it is pretty easy to tell the system it is now operating in a different country (e.g. setting in Web UI) and then it will not comply to the local radio regulatory requirements any more. From my experience it is not the FCC which really demands it, please blame the chip vendors for binary only driver first.

The worst hacker for a silicon vendor, where they normally protect most against, is some guy like the author of this blog post who analyses his device in much detail and tries to run own software on it which was not verified by the vendor first. Such software modifications could cause worse customer experience because it is performing worse (which is funny if they have to reboot the vendor software every 20 days) or could cause extra support effort.

randomhacker123

قبل 6 سنواتdiscuss

Checking if a code is secure by counting the usage of memcpy is pretty stupid, but very easy, so it is done by checklist experts to check for security. memcpy_s is not supported by glibc and most other libc implementations for Linux, I do not expect this to change in the future. Here is a good analyses of this optional extension to the C standard from a glibc developer: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm All standard Linux tools use the "unsafe" functions from the libc. You should not use gets(), there are better alternatives in your libc. ;-)

You can link one of these libraries against your code on Linux to get the Safe C functions: https://github.com/rurban/safeclib https://sourceforge.net/p/safeclib/code/ci/master/tree/

Changing an existing code base from the normal glibc C functions like memcpy to memcpy_s is not easy, you do it wrong in 10% or more if you are not the original author of this code or do not have very long experience with it. Even when you are an expert a lot of problems are getting introduced, this is from my own experience. This is not a search and replace task for a junior!

Having one team developing something and then an other team making it secure is not working from my point of view. You should teach all your developers what they have to look for and why. I think it is important to not only says, X, Y, Z, is banned, but also why exactly and how to solve the use case X, Y, Z were used for.

A lot of the security work is not to improve the security, but for compliance to some guidelines internally or externally. The compliance is checked with some tools, like checking if "grep memcpy(" finds a result. Then the engineer or his manager will use the cheapest solution to solve this like Huawei did here.

To improve the real security you need some experts looking with the original developer into the real code. These experts do need more experience than just good PPT and Excel skills, but they need some knowledge in such software, probably different people for an embedded controller than a node.js application.

randomhacker123

قبل 6 سنواتdiscuss

The pressure from the device vendors to the SoC vendor to support the kernel version which was initially used for the SoC and fixing bugs and adding new feature is much bigger than the pressure to upgrade to new major kernel versions.

The board manufactures normally do not want to upgrade. I very rarely see that device manufactures are doing a major kernel upgrade when a new SDK with support for a new major kernel is available from the SoC vendor. This only happens when they need new features from the new major kernel which can not easily be backported and a very big customer is requesting this and normally they also need a good internal software engineering department.

randomhacker123

قبل 6 سنواتdiscuss

The extra money goes into marketing to tell you that they are the best vendor.

The hardware design and manufacture is outsourced to different vendors, in this case to Foxconn. See here: http://en.techinfodepot.shoutwiki.com/wiki/Netgear_R7000

The software engineering is probably also outsourced mostly.

randomhacker123

قبل 6 سنواتdiscuss

Using an very old and unsupported kernel is completely normal for embedded consumer devices like home routers. Normally the kernel is chosen by the SoC vendor when they start the new SoC project. Updating to a new major kernel version takes multiple man years of work because of all the vendor patches hacked into the kernel. Probably 500k to 2M lines of kernel code for such a router. After such an update you also have to run all your validation again which also takes effort.

Normally there are 4 years between the start of a new SoC project and the first device with this SoC hitting the consumer market. Then this SoC is used for new projects the next 4 years and shipped in new products an additional 4 years. Now the kernel is 12 years old. ;-)

Even when an SoC vendor provides a new SDK with a more recent kernel, most of the device manufacturers like Netgear would not upgrade existing products to this new SDK with the new kernel. They also have extensions to the kernel and would have to adapt them and then do an extensive validation again. Normally even security updates are only taken if someone proves that this specific devices is affected.

Often board manufacturers do not even want to use the new SDK with the new kernel and security updates for new products when they already have devices with the old SDK, because this would reduce their possibility for reuse.

The SoC vendor wants to reduce effort and will avoid to supporting many different kernel versions. If the major customers do not want to upgrade to a more recent kernel version they will stay at something old because the board manufacturers want to.

The problem is that the customer does not care for security. The customer cares for security features you can print on a box, but not for something like fixing publicly known bugs in the kernel in 6 months.

The home router industry is a hardware business, it is run by hardware experts and they run software like hardware. You start a project, build the system (hardware + software)), you validate the features and then ship it. Now you can start the next project.

If you want to change this you have to request this directly, for small customers this is no really useful, but if you are an ISP and buy 500k units a year, then you can put some peruse on the supply chain. Please communicate your requirements often and to many people in your supply chain and not as one of the 5000 requirements in the excel sheet. If you decide against a vendor because of their software, communicate this to them directly and to many people in his organization, to increase the likelihood that it reaches someone who understand this and fixes it in the future. If they improve you can choose between more vendors next time.

comments