No, it’s not the name of the bug itself nor is it a description of what you may do if you happen to be deeply affected by this security exploit. BASH, for Bourne Again SHell, is the most common command line (think, command prompt in Windows) shell in Linux and UNIX-like operating systems, which means that a bug like this leaves many computers connected to the Internet, like servers and even Macs, vulnerable to hijacking.
At the heart of the bug are environment variables, basically a name that is associated with a value, commonly a program or a function. A particular group of such variables get read and run every time a shell (command line interpreter) is run. This isn’t exactly new nor is it particularly worrisome. The problem is that a bug in BASH allows such a kind of environment variable to carry out arbitrary commands or programs, which can then be used to gain control of a system. Add that to the fact that BASH is the shell pre-installed and used on many web servers and programs, like Apache, DHCP, and more, on the Internet and you’ve got a recipe for disaster.
Already this bug, which doesn’t have a catchy name, is being compared to the Heartbleed OpenSSL bug and believed to be even worse. While Heartbleed’s exploit only allows third parties to snoop in and listen on data packets, this BASH vulnerability will actually let hackers gain direct control of targeted computers. That said, due to the severity and far-reaching consequences of the bug, many server administrators have immediately taken action. Popular Linux distributions such as Red Hat, Debian, CentOS,and Ubuntu used to run web servers have already issued security patches that users, referring to administrators, can use. End users, both on Linux and Mac, will have to wait for their software providers to release the fixes, which is hopefully very soon.
It is quite worrying that such a bug would have existed undetected for years in an open source software such as BASH. With Heartbleed, this is the second large scale vulnerability found from a software movement that prides itself in allowing more eyes to lay all (or most) bugs bare. Of course, no software is perfect, whether it be open or closed source. Fortunately, it seems that no actual exploit has actually happened during that time. That said, it is also quite telling how fast software distributors are able to respond and release a fix that enabled server owners to quickly plug up the hole, something that can’t be commonly said of more proprietary platforms.
SOURCE: Red Hat