The world will never entirely switch to node.js - the simple fact is that most ISPs worldwide do not provide node as an option, let alone as the default option - Apache is the default, CGI is dominant due to its simplicity and Bash is the default shell. The sheer mass of Apache CGI sites means that node won't be dominant for many years yet, if at all.
I stated in the OP that embedded Unix uses ash rather than Bash by default (it matters not one jot that its BusyBox or some other Unix variant), and FWIW, the Bash vulnerability goes back way more than 4 years - its pretty much been there since inception - certainly more than 20 years in the GNU chain (which is the one that everyone, including Apple, uses). FYI - dd-wrt is based on the original GPL'd Linksys f/w which uses ash as its shell. Nick On Saturday, 27 September 2014 20:22:13 UTC+1, Dman777 wrote: > > I use dd-wrt firmware on my router. It's been about 4 years. I can't > remember what shell is on it and I am to lazy to enable ssh to go and check > :P Ether way...it's so old it would be before the vulnerability. > > Again, I wish the world would start using Node.js...no CGI required and > it's the best platform for backend webservers. It's what LinkedIn uses for > their there mobile website connections(50% of all connections). > > -Darin > > > On Friday, September 26, 2014 4:57:32 AM UTC-5, Nick wrote: >> >> Genuine 10/10 nastiness for web-servers that use Bash CGI - you have all >> probably heard about this one - its potentially far far worse than the >> OpenSSL HeartBleed one... This is what I sent to all our staff yesterday: >> >> *Introduction* >> >> Many of you will have read about this in the press. For those that >> haven’t, the simple summary is that the Bash shell that is used to execute >> CGI requests on most of the world’s web servers has had a huge and >> easily-exploitable hole in it for 20 years. As everyone uses the same >> version of the Unix toolchain, everyone uses the same “Bash” and thus all >> Unix-based are equally vulnerable. >> >> Its rated as being far worse in real terms than the “HeatBleed” SSL >> issue, in that rather than “just” being able to trawl the memory space of >> the remote web server for username/password combos or private RSA keys, you >> can basically do what you like - you can execute arbitrary command in the >> context of the remote shell – it’s really easy/trivial to exploit this bug >> – examples in the link below. >> >> RedHat have probably the most concise description of this issue – see >> https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ >> >> Note that the fix that was originally posted was incomplete – a new fix >> is yet to be delivered. >> >> *How does this affect me?* >> >> Possibly a lot, in that sites that you access and which have your data >> stored on them may well be completely open to attack. If you run your own >> web sites (nearly all run some variant of Linux), you should replace your >> Bash as soon as an approved fix is available. >> >> However, there is nothing you, as a client browser, can do to lessen your >> chances of being indirectly affected by such an attack – its server-side >> only and therefore up to each Unix-based website that used Bash-based CGI >> scripting to implement the fixes ASAP, or to simply disable Bash CGI until >> the fix is made. >> >> >> This is being actively used in the wild already - a botnet was discovered >> within hours of the announcement - cunningly, it uses wget or curl to >> download the botnet precursor, does a chmod 777, then executes the >> downloaded code to subvert the host and add it to the botnet. >> >> EDIT:Just had a thought about all this – most routers/firewalls run some >> form of embedded Linux – typically a version of BusyBox – if you have >> external (Internet-facing) HTTP or HTTPS access enabled for remote >> management etc., then you may well be vulnerable and should seriously >> consider disabling remote management on the router until the supplier >> provides a safe upgrade… specifically, if the shell in your router is >> "bash", then disable remote http[s] access; if its "ash", you should be ok >> - BusyBox uses "ash" by default. >> >> >> Nick >> > -- You received this message because you are subscribed to the Google Groups "neonixie-l" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/088fefcf-12ea-449b-bf0e-f6c7d57613ce%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
