Is ST Cube IDE a piece of buggy crap?

[peter-h]

Every month there came more hacks and vulnerabilities, my point of view never ever do this yourself, you just can't update. You need the specialist firms.

I don't agree; if you want a box which is open to the internet and needs to be resistant to the best of chinese and russian attackers then forget any embedded solution. For a start you probably can't upgrade it, and the upgrade process itself is a huge back door, so you need certificates, but these are worthless unless you have 100% solid physical security of the product.

Most IOT boxes are in the hands of the attacker

That level of resistance needs a proper server, like Centos or Linux, and NGINX or Apache, the usual heavy duty heavily tested server side stuff used these days. And firewall them; in some applications accepting traffic only from an IP range.

Nothing wrong with LWIP and anybody telling you otherwise is making you pay for nothing

[Kjelt]

It all depends on the application. Any discussion without context is useless.

[peter-h]

The context is whether the Cube-packaged stuff like LWIP/MbedTLS is actually insecure and will get successfully trashed if deployed on an open connection.

It certainly is - it has to be simply because it has not had the attack exposure of the full size server systems - but I am saying this doesn't matter, for the reasons given.

Quite what I would do if I was building something like a domestic heating controller with remote control capability, I don't know... TLS is of little help because it runs on top of LWIP.

Maybe LWIP is a lot better than people say, and the commercial alternatives are just getting money for snake oil?

I am on mailing lists for LWIP and MbedTLS. The LWIP one is pretty quiet and there are very few replies to questions. Very little going on. The MbedTLS one is more "energetic" and regularly talks about security improvements, but the stuff in there is the same stuff we have been heating for many years. For example the latest version zeroes some buffers before heap de-allocation, which is "nice" but what the hell does that do? Nobody is going to get access to freed block RAM until they have totally penetrated the product; basically running their own code on it, but how would you do that? In most scenarios there is no filesystem on which you could install some executable, so the attacker's code would need to be running in RAM. I think this is mostly snake oil.

[paulca]

Every month there came more hacks and vulnerabilities, my point of view never ever do this yourself, you just can't update. You need the specialist firms.

I don't agree; if you want a box which is open to the internet and needs to be resistant to the best of chinese and russian attackers then forget any embedded solution. For a start you probably can't upgrade it, and the upgrade process itself is a huge back door, so you need certificates, but these are worthless unless you have 100% solid physical security of the product.

Most IOT boxes are in the hands of the attacker

With ADR this is such a typical understanding of IT security that it's usually the number one type of case study we look at.

They don't need an open port.  Very few hacks actually come via vectors you know about. 

As an example.  You can take control of a Tasmota device and use it to infiltrate a network, gain full access.  Without even getting out of your car.  The attack is very simple.  Blast it with jamming until it reboot, repeat.  Eventually it will come up in it's "Emergency Access Point" mode with a default password.  BOOM we are in.  Quick OTA flash of the red-carpet payload.  Then where can we get to from this poxy little ESP.  Well, that's usually simple.  The Wifi password is stored un-encrypted in the flash in a known location provided in the Tasmota code.  No need for a red carpet root kit, just ask it for the password and you have FULL access to the house/building network.

It's not even like these are really smart diligent people.  They aren't.  They just buy exploit scanner packs and tools.  Run them in as many places you shouldn't as possible you will get hits all over the place from Wifi devices.  My network neighbour hood has a few unsecured devices on it and a few which known hacks.

Now some of the hacks and attacks you see on the news are over-inflated and not really of consumer interest.  They are more of interest to large companies who have people with physcial access they do not trust.  Security does NOT end if you have physical access.  Consider a bank cash machine.

A would honestly suggest even a quick dip into the world of modern IT security to see how much of a wildwest it is and just how creative and innovative hacks can be. 

I found that unless you think like a scum bag criminal you won't think yourself ahead of them.

[peter-h]

Well, yes, if somebody has set up a WIFI AP which contains the credentials to connect to your factory LAN, and that AP is physically accessible to an attacker, then your security is zero. Because that AP must store the credentials in plain text somewhere. Or encrypted under a key but that key must be stored...

I too remember the days of Netstumbler, WIFIfofum, etc They probably still work in some places. In the old days, I could drive 10 miles and log 600 unsecured WIFI APs...

But you cannot control your customers' stupidity. What you don't want to do is sell a box which can be hacked remotely. Unfortunately IMHO this is not avoidable if running "simple" embedded products. I think most IOT devices can probably be easily crashed by malformed packets, but that in itself won't get you anywhere.

Cash machines use a special tamper-proof module to store important stuff, like the key which is needed to change the PIN number on your card. This is a surprising weakness of the whole system. Someone told me many years ago the PIN number is (or was) encrypted with DES and stored on the card thus. So the cash machine needs to contain the DES key. DES is highly secure in a commercial context (yes I know the hype all over the internet about deprecation). It uses a module which (I know only how it used to be done years ago) you have the circuit board, encased in glass which contains a wire, and if you get in you break the wire, and the SRAM holding the key(s) is erased. This stuff was developed to a high degree in the 1990s onwards. I had a customer in that field. Nowadays, smartcard chips claim to be as good but probably are not. If you need key and certificate storage which is resistant even in the hands of an attacker (a cash machine is easy to steal, with a JCB) then you need to use something like this. And it is a hassle, not only because you need to use the CPU in the smartcard for some processing. I designed a product many years ago with the Siemens 44C200.

[Kjelt]

The context is whether the Cube-packaged stuff like LWIP/MbedTLS is actually insecure and will get successfully trashed if deployed on an open connection.
It certainly is - it has to be simply because it has not had the attack exposure of the full size server systems - but I am saying this doesn't matter, for the reasons given.

You can discuss if the STM32 has enough beef to be interesting to hackers. But as paulca already stated it can be the first step into the network to jump from there to other more interesting and capable equipment.
Anyway security is a specialists job, to the outsider every hack looks like "oh that is far fetched no-one is going to do that".
The problem is that those hacks even the ones from academic perspective are published and every hacker follows those publications and sift through the interesting ones.

[paulca]

But you cannot control your customers' stupidity.

But... you CAN find yourself liable for it.

Consider the volume of "Smart" devices being sold.  Do you really think they are all being bought by IT smart people?  Do you think people understand if their Ring Doorbell is being watched by pe-dos?  No.

However, if you are a large organisation selling that platform to customers in enough quantity that it gets national press coverage surrounding its vulnerabilities.  If you are shipping a few 100 or a few 1000 products, you might get away with the 2 or 3 people who get hacked.  If you are shipping a million products a month and 10s of millions of people are using your devices.  You will absolutely find yourself becoming responsible for your customers security or being put out of the market by other means.

[Kjelt]

However, if you are a large organisation selling that platform to customers in enough quantity that it gets national press coverage surrounding its vulnerabilities.  If you are shipping a few 100 or a few 1000 products, you might get away with the 2 or 3 people who get hacked.  If you are shipping a million products a month and 10s of millions of people are using your devices.  You will absolutely find yourself becoming responsible for your customers security or being put out of the market by other means.

What I saw in the past for instance with the famous "babywatch camera's" that the company can not fix it and just declares the product obsolete , stops any (external server / update) support and emails the customers that did register their product that it should not be used anymore.
Really nice huh? People bought a $99 babywatch camera and two months later they are mailed with don't use product it is unsafe, support ended.
I don't think a EU/US company would get away with this, on the other hand who is going to file a lawsuit against them ?

[paulca]

I don't think a EU/US company would get away with this, on the other hand who is going to file a lawsuit against them ?

Yes, getting the liability to stick is an issue.  Localities have outdated "unsafe product" legislation which is incompatible with the current import market on ebay and amazon. 

Amazon have been fined, called out etc.  repeatedly and repeatedly they remove products from sale, based on "consumer" and "consumer lobby groups" are dodgy fake CE stamped goods.  Yet, I'm sure it's now just a balanced line item with efforts to prevent them appearing in the first place.   I'd figure Amazon can get away with a little "better to ask forgiveness than permission".

If you buy from a UK seller you have more rights in the UK, it's not meant to work that way, but it does.

Most people know this.  If you buy from a chinese supplier, you are NOT sending it back, even if it arrives smashed.  It's buyer beware.  If you want more consumer security you have to buy from someone who has made their product meet those more stringent tests, that's been through industry approved pen testing, electrical testing etc.   Then if it sets fire to your bed or lets hackers in through negligence you might have an avenue to claim, if the company still exists.

[peter-h]

Let's get to something specific.

I want to make a "babywatch" camera.

Does this come up on an open port, having used its installation utility to open a port in your "PnP" domestic-grade router? Or does it just have a wifi connection to your LAN, and you point a browser to that IP (etc) when you are in the room next door?

What is the attack surface, and how would a commercial TCP/IP stack help compared to LWIP?

If you think you can sue the company from which you licensed the commercial TCP/IP stack, you are kidding yourself First you will find anything really hard to prove i.e. how did pics of your baby appear
on dodgy Russia-hosted websites... Most likely because you used credentials of admin, and your birthday And if this device was LAN-internal only, then somebody parked outside your house and logged into your home WIFI with some obvious credentials, and then what exactly did you get by paying for that stack?

[paulca]

You can start here:
https://www.hackers-arise.com/post/google-hacking-the-ultimate-list-of-google-dorks-to-find-unsecured-web-cams

Google will find you some.

However, most of the high profile "hacks" regarding baby cameras have been online cloud services.  Almost all consumer camera devices these days do this.  Consumers cannot be expected to figure out how to provide their own remote access, so videos get uploaded.  That focuses the attacks onto a bigger basket of eggs.

[peter-h]

That is at least 20 years old. It started when AXIS started selling lots of ethernet connected cameras. These had an HTTP server which could stream the video. Most people installed them and didn't change the default credentials. As the article shows, google finds these and using suitable search terms you can find them.

It is the same procedure as finding all PHP-BB forums which run on a specific version of PHP and a specific version of PHP-BB. Or Magento online shops which have not been patched to a specific level.

Marketing a "cloud server" is the right way for "IOT" boxes to be online (they are thus a client not a server) but it crucially delivers a steady income stream to the mfg because he charges for the server

I still see nothing on the topic

[Kjelt]

If your online embedded device has an unique identifier for instance shodan can find every one of them that is accessible.
And that is amateur time, real hackers have uncountable bots looking 24/7 for all kinds of devices, entry points etc.

https://www.shodan.io/

[Kjelt]

Marketing a "cloud server" is the right way for "IOT" boxes to be online (they are thus a client not a server) but it crucially delivers a steady income stream to the mfg because he charges for the server

True if all your ports are closed for the outside and the IoT device just phones home and mutually uniquely identify themselves to the server according to the latest security specifications that is pretty safe.

[peter-h]

No disagreement there. In fact far less "security" is needed then, because the IOT box is

- behind NAT
- doesn't need a published DNS record
- can be firewalled to not accept inbound traffic outside an established session, and allow outbound traffic only to a known server IP
- not accepting inbound traffic anyway (no server service) by design
- it's hard for an attacker to even discover that it exists, let alone what it is

But, still nobody has offered a view on why a commercial TCP/IP stack is better than LWIP

[Kjelt]

But, still nobody has offered a view on why a commercial TCP/IP stack is better than LWIP

Because they keep developing, testing and you get support. At least the good companies will.

Although you mentioned 100 mandays work, which sounds much, that is pretty much on par with my previous company experience.
Does ST nowadays also give code for the PHY because I remember that was also a PITA to get that properly working.

[Kjelt]

And indeed commercial of the shelf can also be a pitfall:

https://www.eevblog.com/forum/microcontrollers/anyone-used-the-wiznet-ethernet-chips/msg717973/#msg717973

[peter-h]

Interesting thread from 2015. Yeah - all been done before.

The 32F417 talks to the LAN8742 via a funny 64 bit USART. ST supply the code for that and it seems to work. I played around with that a little bit when doing a fast data save function on loss of power; shutting down the LAN8742 saves about 50-100mA immediately and was the lowest hanging fruit of all the chips I have. I posted the full details here

I don't believe a commercial stack is better than a free one, inherently. Commercially, you have far fewer users writing code, especially ones doing different stuff and exercising edge cases, especially if you charge 4 figures. And a key thing is that in the commercial sphere you will always cover up issues. If one of your dev customers posts about a problem on some forum, his throat will be cut immediately (his support will be terminated). I've seen this many times in other areas.

True about support, but LWIP is about 16 years old now. Nobody is too interested in it. Those who could help have written it all before (mostly).

[peter-h]

Is there any solution for Windows to Cube's focus capture?

When you build a project, Cube IDE captures the keyboard focus at the end of it, so if you were typing something in another application while building the project, a number of keystrokes will be captured into the current Cube IDE edit window.

[peter-h]

Is anyone using Cube IDE with a Segger debugger and, if so, is the interaction any different?

I had a play with the Edu a while ago and it seems to work fine for simple breakpoints.

Can anyone comment on reliability? The STLINK connection fails usually after some hours but users report this as normal.

[Kjelt]

Can anyone comment on reliability? The STLINK connection fails usually after some hours but users report this as normal.

Call me stupid but I am glad that a high speed debug session will last an hour. Those are running at 10MHz or more. Any pulse in the environment (something heavy relay switching) can cause an error.
If I need to debug something that occurs sporadically over multiple hours or even days, I use my own breakpoint debug code. Just write to any interface/memory that is not part of the issue.
Usually I reserve a small part of RAM , fill it with the data if the issue occurs (breakpoint is replaced with small piece of code) then write it to an external NV storage device.

[peter-h]

Interesting.

Yes of course normal debug output will always work.

I actually wonder if one could use the breakpoint system in that way. AIUI, the CPU implements ~5 hardware breakpoint (address) registers, and executes some piece of code when one of these gets hit. The ST / Cube / Eclipse handling of this is obviously marginal, but the original trap is probably 100% reliable.

It should not be too hard to do i.e. use breakpoints but not via the debugger. You need to write some code which, at the simplest, collect the register values. The Cube stuff collects variable values as well, which is more work but feasible where they are in RAM. Statics can be extracted from the .map file. Locals, not sure.

Bypassing the crappy SWD interface would be great.

One can drop the clock speed but it doesn't help much.

I don't think it is some simple signal integrity issue because sometimes the debug mode runs for days. For example I found that using the SWV ITM console for debugs breaks the debug mode pretty fast.

[NorthGuy]

Can anyone comment on reliability? The STLINK connection fails usually after some hours but users report this as normal.

Call me stupid but I am glad that a high speed debug session will last an hour. Those are running at 10MHz or more. Any pulse in the environment (something heavy relay switching) can cause an error.

JTAG has an ability to recover from failures, so there shouldn't a problem if something goes out of sync.

[peter-h]

Should, but does not

I have run a number of targets with a number of PCs and all of them lose debugger connection eventually. There is for sure much commonality there but almost everybody else has reported this problem.

Reducing the debugger clock speed, even down to silly values like 1MHz (and remember the STLINK V3 ISOL won't run above about 8MHz anyway) does not help. Actually, the AUTO clock speed setting is hardly going to be reliable because ST probably step through the clock speeds until it fails and then step back a bit.

ST uses SWD, not JTAG, but I don't know the difference.

[peter-h]

I think I have found what is causing the random file opening in Cube.

In Debug mode, if you click this to restart the target


then it opens a "random" file but the file opened is the code which was running when the target was reset. Which file is opened, is wherever the CPU was when the above button was pressed.

So the file opened is not "totally random" but is not desirable to have it opened; it serves no purpose. It means that if you restart the target say 20 times, you get 20 file openings, and depending on where the CPU spends most of its time, you may get 20 different files, or fewer. If for example CPU spends a lot of time waiting on some mutex, then over 20 restarts you will get mostly tasks.c (the FreeRTOS main file) opened, but you may get other files so if e.g. the mutex is around some SPI code, you will get tasks.c and sometimes spi.c. Eventually you will get loads of different files opened.

This probably explains why some people get it much worse than others.