Of course, the news blows this out of proportion being it's full of non-tech apple users in the media.
Most embeded devices that use linux use busybox shell, not bash. Also, the media fails to mention that a user first needs access to a system running bash...ssh itself does not run bash. Ya, that is a drag about web-servers using CGI being vulnerable. BUT...if people used Node.js, the most superior webserver/platform in world :), they would not have this issue since Node.js type web servers do not need any CGI...they sit behind a front end reverse proxy(Nginx, etc) and listen on localhost. No interface necessary at all! In addition...native non blocking I/O. Something CGI's require tweaking/bloating to accomplish. -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/6dd50bfc-e989-4953-a3ad-15c60fe3b066%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
