The newly ‘released’ bash bug is a bit of a heads up for IoT folks as it impacts just about any system with a *nix in it, which likely means at least some IoT devices are now up against the wall from an attack perspective.
Have a read here:
There are now tons of other posts concerning this vul as it could be a biggie.
There is a CERT bulletin for this and I would think more to come given the nature of this exploit. I should also mention that a ‘patch’ was released called ShellShock but its already been blown up (ie didn’t work).
Wow this could be a big problem. It should only pose a big problem on devices that are exposed directly to the Internet. Even if it is just the Apache web browser. I could see AP/Firewall devices being a huge target. They mentioned smart light bulbs, I don’t know how many of them are running Linux.
This does add to my fear of using embedded Linux. I believe the open nature will help speed the repair process but it doesn’t seem to prevent the problems from being there in the first place. (I think open source did help in the past however.)
Just out of curiosity has any issue like this or Heartbleed been found on WinCE devices?
To avoid attacks we all should go back to hack in code in pure byte code and run no two devices with the same version of the code.
So a security related bug is only a thread for a hand full of devices.
That’s not really fun for hackers to find them.
8)
Back to my comment earlier to Windows on devices. us a bad idea, so is Linux and any full blown operating system.
IoT is netmf all the way, a perfect match made in heaven. And for supper tiny devices, just pure native coding is best, like mbed. What a “coincidence”, support both.
I don’t use a screwdriver to drive in a nail. Each tool has a purpose.
For example, if I want to stream 800x480 video over WiFi , how would I do that with NETMF/mBed?
I’ve not tried this yet, but I would imagine that it would pretty quick and easy with a Pi/BBB/MinnowBoard Max/etc.
Many project showcases with Pi/BBB are easily done with a mCu based systems. But there are certainly times when it makes sense to use an OS based system to compliment an mCu or to use by itself.
@ mhectorgato - when we say internet of things I not think of a media player! I think of a Wi-Fi coffee maker and an Ethernet dish washer. Take a look the video sparkfun made for the intel board running Windows and listen to what examples they brought up. All of the examples would be a perfect fit for netmf, definitely not Windows nor Linux!
Agreed - each tool has it’s purpose. You can drive a nail into a piece of wood with a wrench if you wanted; or you just use a hammer.
The demos where they show a Pi controlling a little rover, to me it’s like using an impact hammer with the explosive cartridge that you use with concrete instead of a simple hammer.
Caveat – that the Pi and similar can be cheaper than similar Gadgeteer/NETMF solutions, so it might “make sense” from that vantage point.
While it may not make sense to have a “computer” in everything today. I think at some point the price will make such concerns irrelevant. Though it may be awhile before this happens.
Well, why not implant a BLE in a servant and be alarmed when too far away or better yet the further away the more of a pain nerve to stimulate, so they’ll stay close … although that idea is maybe not new … I think I heard about that before …
@ hagster - I guess it depends on what you mean by “secure”. I think there are different aspects to security.
You mentioned “physical access”. If an attacker can gain physical access to any device, linux, windows, .netmf or whatever, they can pretty much do whatever they want. Given unfettered physical access and the right tools it is pretty much impossible to prevent someone from reflashing a device with malicious code. (As a side note I do get a small laugh at some of my large industrial customers who fret over wireless security when someone can walk on site and have access to hardwire network connections that are exposed on outdoor equipment.)
Authenticating updates that are downloaded from web servers or pushed remotely is very important. I haven’t done anything (yet) with remote updates on .netmf so I don’t know what is involved in securing them.
For me I lose far less sleep knowing my 2000+ devices that I have currently in the field are not running any type of high level OS like Linux or Windows. I couldn’t imagine the nightmare of getting my customers to update their software. The worst thing an attacker could do is hit it with a DoS attack and lock up the little 8bit processor. I think the same could be said for most .netmf devices.
I agree with you that using .netmf doesn’t excuse us from not taking security seriously. It is entirely possible to write an application using .netmf that could be hacked to do something nefarious. Poor code is problem regardless of device. However, I think it is easier to make mistakes and write bad code when you have a big OS running your code. This Bash bug is an example of that; as well as other type of code injection exploits.
@ skeller - it’s good to ensure that if someone gets access to one device (perhaps they bought it) they can’t extract information that could compromise all other systems.
With Linux its much harder to understand exactly what code is running on your system. Good practice is to remove all unnecessary processes as they just add additional attack vectors. I pretty sure this rarely happens. It’s more like ‘let’s just start with distro x on this board because we know it works and not remove anything because we have a deadline.’
First of all, NETMF uses OpenSSL. Heartbleed anyone? OpenSSL is just plain bad, in terms of security and also in terms of RAM and flash footprints. Half of it is obsolete code (but still an attack surface). Ten times as large as necessary I’d guess.
Then the current NETMF design seems to work with encryption, but not with authentication. Encryption without authentication is a bit of a joke, unfortunately.
For our Limmat project, we are bypassing the whole network design of NETMF (which we don’t need as much as on our Mountaineer Ethernet Mainboard, as we don’t use lwIP anyway on Limmat).
In regards to Heartbleed I am curious if anyone has attempted to test the flaw on .netmf. According to this: https://www.openssl.org/news/secadv_20140407.txt Up to 64K of memory can be reveled, from the client or server, in each heartbeat message. In the context of .netmf what memory would be exposed, RAM or Flash? I see the potential that if either were exposed any embedded passwords or security keys used to access other servers could be exposed.
If I understand Heartbleed correctly a .netmf device could be compromised in two ways:
the device would have to connect to a compromised server using SSL/TLS. (i.e. a server that is compromised to exploit the Heartbleed flaw on a client.)
a device that was operating as a server and using SSL/TLS to secure the connection.
Does that accurately sum up the issue? I am trying to get an understanding of the flaw in context of .netmf.
