The code that caused Heartbleed was checked in December 31, 2011, and released as OpenSSL version 1.0.1 on March 14, 2012, what is the date for the OpenSSL code used in .NetMF?
Agree, also I’m concerned will the number of products using openSSL. Identifying and upgrading/patching is a nightmare.
Another article about ShellShock:
Apparently Bash was originally written by a high school dropout.
Let that sink in for a minute. A software component that is on millions of computers throughout the globe, many of which leverage it for CGI scripts in a way that makes the remote exploit of this bug possible, and all of it started with a high school dropout.
And before anyone gets their back up, I’m sure he’s a very smart high school dropout. As someone who doesn’t have a CS or EE degree, I’m well aware that you can be a good programmer even lacking those things. But if someone was setting out today to build a shell for an internet-connected operating system, can you possibly imagine that the person you’d hire to build it would be a high-school dropout?
And FWIW, I never want to hear anyone ever again tell me how secure OSS is by virtue of the “many eyes” law. 22 years this bug has lain in wait.
The part that gets me most is the last paragraph of the story. I can understand taking pride in the ubiquity of software that you wrote. But the week that a major flaw in that software was widely announced (even if the bug was added by someone else) is probably not the optimal time to express that pride.
4 Likes
In my opinion it is this type of vulnerability that should make embedded developers nervous about using an operating system like Linux in their large scale or deeply embedded projects.
3 Likes
I have to say, I was pretty freaked about it, particularly given that many, many routers run some *nix variant. Was only able to relax (a bit) once I determined that my router doesn’t run Bash.
Of course, who knows how many more “shallow bugs” are waiting to be discovered and/or exploited? Sigh.
I can agree with that. Using bare metal code or something like .netmf does give a little cushion because of obscurity. I know “security through obscurity” is not something to rely on it does limit your exposure somewhat.
I think Apache uses bash to run CGI scripts. Your point is still valid.
I still think the question, like many of these issues, is what is the potential impact on me? I know how my dumb toaster works, but what about my internet-connected fridge or TV, or as @ devhammer points out, my internet ingress/egress router? And for me the risk is somewhat lessened by me being “smart”, but in a truly connected home with “consumers” alone, they’re not going to know what to do or what to look for. The security pattern that has been built up over the years with “mature” offerings helps a lot in the consumer sphere, but the immature/emerging areas like IoT/connected devices is certainly playing catch up. Mandatory security update practices that consumers can follow has to be the minimum benchmark - automated is even better.
But that’s the problem…one would think, given years of development, that WiFi router firmware could be considered a “mature” offering, but plainly that’s not the case, because someone, somewhere, made the assumption that the software they chose to use as the basis for that firmware (namely, *nix) was secure. Granted, the particular vulnerability of the moment would require that Bash be the particular shell on the router, and would require some form of remote access, which hopefully would not be enabled by default. But even with a limited potential for exploit, how on earth do I tell my mom how to check her router to see if Bash is enabled? Especially since it was hard enough for me to figure out on my own router!