surprisngly few. Ciscio IOS, and a few realtime ones spring to mind.
But unless you ae prepared to pay over £500, you wont get cisco IOS.
Anyway this has nothing really to do with Linux-the-kernel. But Linux-the-distribution.
Not all linuxes have bash, and of those that do even fewer use it as te default shell script, and of those that do, even fewer have that exposed to attack.
And not a few NON linuxes like OS-X HAVE got bash as the default script. Oh dear. In fact apple machines are the most vulnerable.
Name them.
stating facts is not fanaticism dennis. denying them is.
Not particularly. I'm told that this has to be the scenario (and most Mac users don't do any of the following):
A little more than that:
Have Apache running on a Mac reachable from the WAN. For a typical home user with an ISP-supplied internet router and a computer sitting behind that, this would require router settings modifications to open and map web server ports to a computer, and would also require the user to start the Apache web service so it is listening for connections (which requires either familiarity with the Unix command-line environment, or third-party GUI software).
Have Apache configured like so:
a. Have the CGI module (cgi_module) loaded. The module is *loaded* by default in OS X 10.9 Server.
b. Specify a directory to hold CGIs with ScriptAlias directive(s). This is pointing to the *nonexistent* directory /Library/Server/Web/Data/CGI-Executables by default in 10.9 Server.
c. Optionally enable .htaccess support for CGIs:
Activate the cgi-script handler. The handler is *active* by default in 10.9 Server.
Have .htaccess file support enabled. This is *disabled* by default in 10.9 Server. A server administrator may enable .htaccess file support in one or more of the web servers configured in the Server application, on an individual basis.
Allow the ExecCGI directive to be used in .htaccess files. This is *enabled* by default in 10.9 Server.
Add: Options +ExecCGI to one or more existing .htaccess files within the server document root. htaccess files *don't* exist in the web document root by default in 10.9 Server; they would be created by the user.
Have an actual CGI in one of the CGI directories specified by the Apache configuration. This CGI must:
accept parameters during submission
do something with the accepted parameters that triggers the ShellShock bug
The X25 card I designed and programmed used RMX86. The replacement used Unix SVr5 with a lot of the stuff done in STREAMS modules to get the response times (solaris is based on SVr5 just JFI). My router uses BSD. My NAS boxes use linux with busy box not bash although I could install bash or even a debian distribution if there was a good reason to (anything else would need a recompile). My mail server did have an Intel RTOS on it but I have dropped it (literally). Other cards in System X had OS kernels I did myself. The bit slice processor used by the main exchange used a RTOS designed in house. The adjunct processor used a unix like RTOS which I forget the name of. The softswitch used the same as the adjunct.
Of course I have also used cisco kit, juniper kit, iron moutain stuff, and lots of stuff that I have forgotten (including pyramid, sequent, tandem).
Any of several methods that allow CGIs will do. For example, having "AddHandler cgi-script .cgi" and "Options ExecCGI" in users/someuser.conf.
I'm not sure what you mean by "accept parameters". Any CGI script that is a bash script will do, even if it does nothing. Also a script in any language that runs something that is a bash shell script, unless it takes special precautions to clear the environment.
Plenty of 2nd hand Cisco kit around, I've had an 837 for ADLS1 and now have an 877 for ADSL2, will keep an eye out for an 887 if VDSL ever comes this way ...
They've lightened up somewhat, typically the most recent version of the 'ipbase' or 'universal' image is available regardless of contract, the snag is that recent versions require more RAM/FLASH than older models have, and you *don't* want to be paying for hardware upgrades.
Only the 'ipservices' image requires a contract to download, and if you insist on running IPV6 or OSPF at home there are ways and means they even helpfully publish the MD5* hash of the image for you to check whether the Russians have tampered with it.
[*] Of course SHA-x would be nicer, but what value of x for the paranoid?
I wrote a script that given an IP address would ping it then if it replied search the ARP table for the corresponding MAC address, then search the MAC table to see which port it's connected to ... it worked but it made perl look readable.
True, but I think they would be laying themselves open to all sorts of legal challenges if they didn't make basic functionality available. Without it the hardware is just so much landfill. It would be like selling a PC motherboard without its BIOS code.
quite.
And the ipservices image (plus others if you have a model that can't take the 'all-in-one' image because it's too big to fit in flash, and have to try and work out which of the many images on offer actually contains the functionality you need) is the one that contains useful functionality, such as IPSec, VPN, etc. It's also needed if you add, e.g. hardware encryption/decryption accelerator cards or network interfaces on plug-in cards.
Ah yes, been there, done that, not felt comfortable with it at all.
I really hope Cisco, Juniper et al are worried about the current trend towards producing open-source routers:
formatting link
Cisco has been screwing its customers for years and the tide is starting to turn. I'm just a little concerned that Huawei may get in on the act
- I wouldn't trust any of their kit further than I could throw it.
By the way, Cisco is in panic mode patching its gear against ShellShock:
iptables and openVPN live on a WRT54GS here, if I could buy an ADSL router that ran openWRT, I would ... shame the beatsasitsweepsasitcleans Fritz!box doesn't play nice.
Yeah, plenty of sites with Nexus switches and a *lot* of their telephony kit.
It's running my NAS box (N4F). There have been no updates since 28 April this year (and I only applied that a week or so back).
A quick look at the N4F (and the FreeNAS) fora indicates these FreeBSD based NASes are also using BASH. I was a little surprised at this. It seems these NAS OSes are potentially vulnerable to the shellshock exploit.
I think I'm ok because the _only_ service I have running is the CIFs/SMB service with everything else disabled. If I want to run Transmission to get some torrents, I only enable it for as long as it takes to get the downloads. Likewise with SSH, I only enable it on those rare occasions when I want a remote console otherwise it remains disabled.
I think the only risky service out of those two is SSH. I don't know whether Transmission provides a path to BASH for the shellshock exploit to use. I'm not a *nix guru (at least not yet!) so I rely on the experience and knowledge of others to inform me of such risks.
+1. IMHO Shell scripts are too risky to trust for anything important.
I fail to remember the syntax so always have to look it up.
And there's one thing I don't get about the "shellshock" bug. Surely being able to invoke a shell command from a web request is a security risk in itself, without needing any bugs?
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.