Shellshock 101: What you should know about the “Bash bug”

By Steve deRosier, Systems Engineer III

Let's get this out of the way first: Laird Embedded Wireless Solutions' Linux Wireless Bridge modules (WB40 and WB45) are in no way affected by the new Shellshock issue. The WB uses Ash (not Bash) as its shell and we've tested it to be sure it doesn't have the bug. In addition, our developers follow long-established best practices and our web interface never passes unfiltered user input to the shell.

When the bug was announced, my initial reaction was that it was overblown. I immediately verified that our WB products do not have this problem and then I researched and learned as much as I could about the ‘Bash bug’. Why did I spend time learning as much as I could about it? Because I knew that it was just a matter of time until someone asked me how big of a deal Shellshock is and if our WB products are vulnerable.

Heartbleed was a serious security problem and, as it turned out, a non-event that was quickly patched and deployed. I believe that Shellshock will eventually end up in the same non-event category but that's where the similarity ends. Here’s why:

• Because it was only in a recent Open SSL version, Heartbleed was limited in how long it had been in the wild. Shellshock, on the other hand, has been in the Bash shell for 20 years or so.
• Heartbleed was limited to a fairly narrow attack whereas Shellshock essentially allows you to write a program with it.

Hence the concern about Shellshock.

But is the sky falling? Seriously. No.

Don't misunderstand me. Because the bug has been around for 20 years and because it can let an attacker effectively write anything, it is serious. But it is significantly mitigated by the layered security model that Linux and other Unix-style operating systems have had for over 30 years.

Consider the following:

• In order to use this bug as an attack vector, an attacker must have a way to get to it. The best access (and the least likely) is someone having an actual shell account on a Linux server. Most people with access to a shell already have trusted access and can do whatever they want; they have no need for this exploit. For the few who may try to use it to elevate their access, they'd likely need to exploit some other bug or security flaw first… one that would provide the access they need even without Shellshock.
• Most experts and media wags agree on one thing: the most likely vector of attack comes over web protocols: http and https. An attacker could send a carefully-crafted message to a web server equipped with Bash and exploit the bug. Basically, this is true. However, it’s important to also know that the number of web servers with CGI applications written in Bash is incredibly small. Even back in the early days of the web it was unusual to use shell scripts to write a CGI http web application. Now, it’s almost unheard of. Most modern web applications are written in PHP, Python, Java, Perl, or Ruby. There are likely some legacy systems running a handful of CGI scripts; and more likely some older embedded systems using Bash as CGI because it was there and the task was simple. The number of remotely-accessible servers that are passing web user input to a Bash script is minute and the likelihood that any of those are accessible on the open Internet is even smaller.
• To take the reassurance one step further… for as long as the bug has been known to exist, best practices for competent web programmers includes NEVER passing unfiltered and unvalidated data to the backend where it could do harm.

While the bug should be taken seriously, it is unlikely that an attacker could use Bash to compromise a system remotely over the web simply because of the layered security model that Linux and other Unix-style operating systems provide and the fact that Bash isn’t typically used for that type of work. In any case, the Shellshock bug has already been fixed and a large majority of systems have already been patched. As stated earlier, Laird Embedded Wireless Solutions' Linux Wireless Bridge modules (WB40 and WB45) are not affected by the new Shellshock issue. Laird’s WBs never pass unfiltered or unvalidated user input to any shell script and we use PHP (rather than CGI) which is not vulnerable to this attack. Lastly, these products are running the BusyBox’s Ash, not Bash, and have been tested to be sure that they don’t have the bug.

Click here to learn more about Laird’s WB40NBT and WB45NBT Wi-Fi radio modules.

Visit the WB40NBT or WB45NBT product pages for Laird's official statement on this issue.

For any support questions, visit our Laird Embedded Wireless Solutions Support Center.